Kryptografie und Verbindungsmanagement von SMART Meter Gateways:

(1)

Kryptografie und

Verbindungsmanagement von SMART Meter

Gateways:

Internetquellen der Masterthesis

Kruetzen, Ingo

[Wählen Sie das Datum aus]

(2)

Inhalt

Admin-Magazin ... 2

BitWorld ... 14

BSI ... 18

Cassandra ... 19

Cryptas ... 20

CUBRID ... 24

Curtalo ... 27

TU Darmstadt ... 31

Datenbank-Engines ... 50

ENBW ... 52

Heise ... 53

HS-Mannheim ... 55

HU-Berlin ... 57

InfoQ ... 76

IT-Administrator ... 94

IT-Wissen ... 97

Krypto ... 98

Meinberg ... 101

Mintert ... 102

Orientation in Objects ... 105

Pacemaker ... 117

Regenachsen ... 119

Microsoft Security ... 123

SSL... 125

UNI-Tübingen ... 129

Zookeeper ... 130

(3)

Admin-Magazin

admin-magazin.de. Abgerufen am 01. 07 2013 von

http://www.admin-magazin.de/Das-Heft/2011/04/HA-Serie-Teil-1-Grundlagen- von-Pacemaker-und-Co

HA-Serie, Teil 1: Grundlagen von Pacemaker und Co.

Der Cluster-Leitstand Aus ADMIN 04/2011 Martin Loschwitz

Unverzichtbarer Bestandteil eines Hochverfügbarkeits-Clusters ist ein Cluster-Manager, der im Problemfall weiß, was zu tun ist. Mit Pacemaker liegt zum ersten Mal überhaupt ein brauchbarer Cluster-Manager für Linux auf der Grundlage von Open Source vor.

Der Failover, also die Übernahme von Diensten eines havarierten Systems auf ein überlebendes, ist das wichtigste Prinzip eines Hochverfügbarkeits-Clusters. Damit der Failover funktioniert, benötigt man eine zentrale Software, die die Steuerung des Clusters übernimmt. Im Fachjargon heißt diese Software Cluster Manager. Ihre Hauptaufgabe ist es, alle Knoten eines Clusters auf Verfügbarkeit zu überprüfen. Darüber hinaus soll sie auch erkennen, wenn womöglich nur einzelne Programme auf einem ansonsten noch erreichbaren Knoten abgestürzt sind.

Ressourcen-Management und Kommunikation

Klassischerweise unterteilt sich das Cluster-Management in die beiden Komponenten Cluster Communication Management (CCM) und Cluster Resource Management (CRM). Für Linux steht mit Pacemaker ein reinrassiger Cluster Resource Manager zur Verfügung, der wahlweise mit den Cluster Communication Managern Corosync oder Heartbeat 3 betrieben werden kann (siehe auch Kasten "Die Geschichte von Pacemaker"). Pacemaker empfängt im

Zusammenspiel von Heartbeat oder Corosync Informationen über die zwei oder mehr Knoten, überwacht deren Ressourcen und greift im Falle eines Fehlers ein.

Die Geschichte von Pacemaker

Wenn Sie sich schon mit dem Thema Cluster-Management unter Linux auseinandergesetzt haben, sind Ihnen vermutlich diverse Begriffe begegnet. Heartbeat, Pacemaker, Corosync, OpenAIS – Einsteigern fällt es oft schwer, zwischen den einzelnen Lösungen zu

unterscheiden (Abbildung 6). Welche Komponente beherrscht welche Funktionen? Der folgende historische Abriss gibt einen Überblick über die wichtigsten Stationen von HA- Lösungen unter Linux.

(4)

Abbildung 6: Wie aus Heartbeat 1 Pacemaker wurde: Die Grafik gibt einen Überblick über rund elf Jahre Entwicklungsarbeit.

Grundsätzlich gilt: Linux hinkte sehr lange hinter anderen Systemen her, wenn es um das Thema Clustering ging. So steht beispielsweise Suns Cluster Suite für Solaris seit über 15 Jahren zur Verfügung. Andere Cluster-Manager wie Veritas haben eine ähnlich lange

Versionsgeschichte. Linux hingegen konnte erst 1998 zum ersten Mal auf so etwas Ähnliches wie einen Cluster-Manager zurückgreifen: Heartbeat 1. Ursprünglich kam die Initiative von Alan Robertson, einem IBM-Entwickler. Dieser hatte sich bereits mit dem Thema Clustering beschäftigt und eine beachtliche Sammlung von Shellscripts verfasst. Für Heartbeat 1 fügte er diese zu einem Paket zusammen und schrieb einige Zeilen C-Code dazu, der diese Scripts in passender Reihenfolge aufrief und dafür sorgte, dass die Clusterknoten miteinander

kommunizieren konnten.

Heartbeat 1 war allerdings in vielerlei Hinsicht sehr beschränkt. Zum einen war die im Artikel angesprochene Trennung zwischen den zwei Cluster-Komponenten – Ressourcen-

Management und Cluster-Kommunikation – bei Heartbeat 1 auf Code-Ebene nicht umgesetzt.

Stattdessen war die erste Heartbeat-Version ein großer monolithischer Code-Block. Auch im Hinblick auf die unterstützten Features war Heartbeat 1 als Lösung für Cluster-Management im Enterprise-Einsatz praktisch uninteressant. Denn es merkte zwar, wenn einer der

vorhandenen Cluster-Knoten ausfiel, und konnte einen Failover initiieren. Ging dabei aber etwas schief, dann stoppte der Cluster-Manager alle Cluster-Ressourcen, und ein Eingreifen des Administrators war unvermeidlich. Außerdem fehlten überaus wichtige Features wie die Möglichkeit, einen Dienst innerhalb des Clusters zu überprüfen (Monitoring) und ihn neu zu starten, sollte er abgestürzt sein.

Red Hat war an Heartbeat 1 übrigens überhaupt nicht beteiligt; die Red Hat Cluster Suite, die bis heute Bestandteil von Red Hat Enterprise Linux ist, lag in Alpha-Versionen bereits 1996 vor und wurde seither konsequent weiterentwickelt.

Die technischen Unzulänglichkeiten von Heartbeat 1 glich später in den Augen vieler Admins ein neues Heartbeat 2 aus. Das kam allerdings erst 2005. Denn besonders dadurch, dass es immer wieder zu Meinungsverschiedenheiten zwischen Robertson und der Linux-HA Community kam, war es schwierig, einen gemeinsamen Nenner zu finden. Heartbeat 2 war letztlich in einer Art feindlicher Übernahme zu großen Teilen von Mitgliedern der HA- Community erarbeitet worden, Robertson spielte bei der Entwicklung letztendlich nur noch eine Nebenrolle.

(5)

Heartbeat 2 räumte zwar einige der Probleme aus, die Heartbeat 1 das Leben schwer gemacht hatten. Denn Heartbeat 2 führte die Trennung von Ressourcen- und

Kommunikationsmanagement auf Code-Ebene ein und hatte erstmals Enterprise-Funktionen wie das Überwachen von Diensten. Das vermag aber nicht darüber hinwegzutäuschen, dass Heartbeat 2 bei seinem Erscheinen bereits veraltet war. Denn in den 6 Jahren zwischen den beiden Releases war in Sachen Hochverfügbarkeit einiges fernab von Linux-HA passiert.

Bereits 2001 hatte sich das Service Availability Forum gegründet, ein Industrie-Konsortium verschiedener großer Anbieter, das einen grundlegenden Standard für die Kommunikation in Multi-Node-Clustern schaffen wollte. Die erste Definition dieses Standards lag 2003 vor, gemeint ist die »Application Interface Specification« , kurz »AIS« .

Außerdem hatte Novell Ende 2003 den deutschen Linux-Distributor SUSE gekauft und wollte SUSE-Linux als Enterprise-Produkt in seine eigene Produktpalette einbauen. Schlagartig war damit auch bei SUSE ein sehr großes Interesse an HA-Diensten entstanden.

Zunächst lag nach der Veröffentlichung des AIS-Standards aber der Ball bei Red Hat. Red Hat stellte einen Entwickler ab, der den nunmehr verfügbaren Standard auf Code-Ebene umsetzen sollte. 2005 erschien die erste freie Implementierung von AIS, die auf den Namen

»OpenAIS« hört. Schon damals war das Ziel, die Red Hat Cluster Suite auf den neuen Standard umzurüsten.

Schließlich ergriff Novell die Initiative: Mit Heartbeat 2 hatte man einen Cluster-Manager, der mittlerweile im Enterprise-Umfeld zu gebrauchen war. Obendrein war Heartbeat 2 auf Code-Ebene sinnvoll zu trennen – der Cluster Resource Manager und der Cluster

Communication Manager waren separate Teile und leicht voneinander abzukoppeln. Das Unternehmen gab dem Australier Andrew Beekhof den Auftrag, den CRM aus Heartbeat 2 auf OpenAIS lauffähig zu machen. Das Resultat dieser Arbeit ist Pacemaker.

Durchaus bemerkenswert ist, dass Beekhof Pacemaker von Anfang an so konzipiert hat, dass er auch heute noch mit dem Cluster Communication Manager von Heartbeat 2 arbeiten kann.

Dieser firmiert mittlerweile als Heartbeat 3. Bei Heartbeat 3 handelt es sich also nicht mehr um einen vollständigen Cluster-Manager.

Die letzte Wendung der Geschichte vom Clustering unter Linux wurde von Red Hat im Jahre 2007 initiiert, hat aber eher geringe Auswirkungen: Der Distributor beschloss, dass ihm OpenAIS als einzelnes Projekt zu groß ist, und spaltete OpenAIS nochmals auf – aus dem Projekt wurden die Komponenten, die sich ausschließlich mit der Cluster-Kommunikation beschäftigen, in ein eigenes Projekt namens Corosync ausgelagert. Als Ironie der Geschichte muss gelten, dass die übrigen Teile von OpenAIS nicht mehr weiterentwickelt werden – OpenAIS ist praktisch tot.

Damit steht fest: Wer gegenwärtig mit Linux-Systemen einen Cluster konstruieren möchte, nimmt dafür eine Kombination aus Pacemaker (Cluster Resource Manager) und entweder Corosync oder Heartbeat (Cluster Communication Manager).

Die Installation von Pacemaker fällt je nach Linux-Version unterschiedlich aus. Debian und Ubuntu liegen fertige Pakete bei. Wer RHEL 6 nutzt, braucht Red Hats HA-Addon; ganz ähnlich verhält es sich mit SLES: Auch hier ist der Erwerb der SUSE Linux High Availability Extension notwendig. Für andere Distributionen ist vermutlich Handarbeit angesagt. In allen

(6)

Fällen heißt das Paket, das Pacemaker enthält, allerdings »pacemaker« – es installiert benötige Software gleich mit.

Admins stehen zu Beginn der Installation vor der Entscheidung: Soll Pacemaker mit dem Heartbeat-3-CCM oder dem Corosync-CCM laufen? Im Alltag gibt es zwar kaum

Funktionsunterschiede, doch beide Ansätze haben ihr Für und Wider.

Soll eine Applikation zum Einsatz kommen, die den DLM, also den Distributed Locking Manager, verwendet, ist Corosync Pflicht, denn Heartbeat unterstützt die Kommunikation mit dem DLM nicht. Auch wer ein Cluster-Setup auf Grundlage von RHEL oder SLES mit dem entsprechenden HA-Addon konstruiert, kommt nicht an Corosync vorbei; denn hier ist Corosync die einzige offiziell unterstützte Lösung. Wer aber Ubuntu oder Debian nutzt, kann sich zwischen Heartbeat und Corosync entscheiden.

Andere Gründe sprechen für Heartbeat: Es unterstützt seit jeher das Unicast-Protokoll für die Cluster-Kommunikation. Corosync kann das erst seit der aktuellen Version 1.3.0 – frühere Versionen kommunizierten nur per Multicast, was zu Naserümpfen bei Netzwerkern führt.

Außerdem bietet Corosync keine Unterstützung für den automatischen Wiederaufbau des Kommunikationspfads zwischen zwei Knoten. Das Feature heißt Automatic Link Recovery und ist bei Heartbeat Standard. Corosync dagegen merkt nichts davon, wenn der

Kommunikationspfad zwischen zwei Knoten ausfällt und später wieder in Gang kommt. Es bedarf händischer Intervention.

Cluster-Praxis

Grau ist alle Theorie – der beste Weg, um Pacemaker zu verstehen, besteht darin, mit ihm zu arbeiten. Das Konfigurationsbeispiel dieses Artikels dreht sich um einen Zwei-Knoten- Cluster. Zwar sind theoretisch bis zu 255 Knoten möglich, real dürfte die Grenze des Machbaren aber bei rund 40 liegen.

Wenn man sich noch nicht für Corosync oder Heartbeat entschieden hat, ist diese

Entscheidung jetzt fällig. Denn Pacemaker lässt sich nicht direkt von der Kommandozeile aus starten. Stattdessen handelt es sich bei ihm immer um ein Plugin, das entweder von Heartbeat oder von Corosync nachgeladen wird. Zuvor sind also immer Corosync oder eben Heartbeat zu installieren.

Die Corosync-Konfiguration

Alle großen Distributoren liefern bei ihren Corosync-Paketen die von den Autoren zur Verfügung gestellte Standard-Konfiguration mit. Das ist vor allem deshalb sehr praktisch, weil darin nur eine einzige Zeile zu verändern ist, damit Corosync läuft. Corosyncs Konfigurationsdatei ist »/etc/corosync/corosync.conf« (Abbildung 1); in der Standardversion dieser Datei findet sich ein einzelner Eintrag für einen

Kommunikationsstring, der allerdings auf die Loopback-Adresse 127.0.0.1 konfiguriert ist.

Hinter »bindnetaddr« in diesem »interface« -Eintrag gehört die Adresse eines Netzwerkes, über das die beiden Clusterknoten miteinander reden. Ist die Änderung

vollzogen, kopiert man die Datei auf den anderen Knoten. Im Anschluss erstellt »corosync- keygen« einen Authentifizierungsschlüssel in »/etc/corosync/authkey« , der ebenfalls auf den anderen Knoten zu kopieren ist. Danach genügt es, Corosync zu starten. Unter Debian

(7)

oder Ubuntu ist gegebenenfalls vorher noch in der Datei »/etc/default/corosync« Corosync zu aktivieren.

Abbildung 1: In den Ordnern

Übrigens: Wer einen zweiten Kommunikationsring verwenden will, kann einen »interface« -Eintrag nach dem Muster des bereits vorhandenen Absatzes hinzufügen, muss diesem aber eine entsprechend erhöhte »ringnumber« sowie eine andere Multicast-Adresse angeben.

Außerdem ist in diesem Falle der Wert hinter »rrp_mode« auf »active« zu setzen.

Heartbeat konfigurieren

Wer statt Corosync lieber Heartbeat verwendet, bearbeitet für die Funktion des Cluster Communication Managers vor allem »ha.cf« in »/etc/ha.d« . Im Standard-Lieferumfang für Heartbeat fehlt diese Datei leider vollständig, sodass sie erst händisch anzulegen ist. Im Listing 1 finden Sie ein vollständiges Beispiel. Die einzelnen Zeilen haben diese Funktionen:

Listing 1

Exemplarische ha.cf

01 keepalive 2 02 warntime 20 03 deadtime 30 04 initdead 30

05 logfacility local0 06 bcast ethx

07 mcast br0 225.0.0.41 694 1 1 08 node alice

09 node bob 10 autojoin none 11 crm yes

• »keepalive 2« sorgt dafür, dass Heartbeat alle 2 Sekunden alle anderen Cluster-Knoten anpingt und auf Antwort wartet. Kommt auf diese Pings keine Antwort, schreibt Heartbeat mit »warntime 20 « nach 20 Sekunden eine entsprechende Warnung ins Logfile. Nach 30 Sekunden erklärt Heartbeat einen Link zu einem Clusterknoten für tot, wenn »deadtime 30« gesetzt ist.

• »initdead 30« legt fest, dass Heartbeat nach dem Programmstart bis zu 30 Sekunden wartet, bis alle festgelegten Clusterknoten vorhanden sind.

• »logfacility local0« legt die Syslog-Facility fest, die Meldungen von Heartbeat erhalten sollen.

(8)

• »bcast ethx« sowie »mcast br0 ...« legen die Kommunikationspfade fest, die Heartbeat verwenden darf.

• »node alice« und »node bob« definieren von vornherein, welche Knoten im Cluster vorhanden sind.

• »autojoin none« verhindert, dass andere Clusterknoten automatisch in den Cluster- Verbund aufgenommen werden, ohne in der Konfigurationsdatei zu stehen.

• »crm yes« aktiviert Pacemaker. An dieser Stelle könnte auch »crm respawn« stehen. Der Unterschied zwischen »yes« und »respawn« ist, dass bei Ersterem Heartbeat einen Reboot des Servers initiiert, falls »crmd« unerwartet abstürzt. Mit »respawn« wird Pacemaker einfach neu gestartet.

Auch Heartbeat wünscht sich einen Authentifizierungsschlüssel, um sich bei den anderen Clusterknoten vorstellen zu können. Der Schlüssel liegt in »/etc/ha.d/authkeys« , bei Heartbeat gibt es aber kein Werkzeug, das diese Datei anlegt. Ein Beispiel – alle Teile mit Ausnahme von foobar sind zu übernehmen – könnte so aussehen:

auth 2

2 sha1 foobar

Ist »authkeys« an ihrem angestammten Platz, startet »/etc/init.d/heartbeat« Heartbeat sowie Pacemaker. Ob Pacemaker läuft, ist mit der obigen Konfiguration nach ungefähr einer Minute daran zu erkennen, dass »crm_mon -1 -rf« beide Clusterknoten als »online« sieht.

Kommunikationspfade

Ein abschließendes Wort zur Cluster-Konfiguration – grundsätzlich gilt: Die Knoten eines Clusters sollten redundant miteinander kommunizieren können, also mindestens zwei voneinander unabhängige Kommunikationspfade zur Verfügung haben. Falls ein

Kommunikationspfad stirbt, steht der andere noch immer zur Verfügung. Sowohl Heartbeat als auch Corosync unterstützen Setups mit zwei Kommunikationspfaden. Achten Sie darauf, dass bei mindestens einem Kommunikationspfad eine direkte Verbindung zwischen den zwei Clusterknoten existiert – also eine, die nicht durch Switches geht. Wenn DRBD im Cluster zum Einsatz kommt, kann der zweite Pfad auch einen eventuellen Back-to-Back-Link verwenden.

Ressourcen

Zentral ist im Pacemaker-Kontext der Begriff der Ressource. Er wird einem im Cluster- Kontext immer wieder begegnen. Er meint nichts anderes als einen Dienst, der von Pacemaker verwaltet wird. Es kann sich also um eine DRBD-Ressource handeln, um eine MySQL-Instanz oder auch um eine IP-Adresse.

Pacemaker selbst ist der Ressourcen-Manager – aber wie wickelt er das Management von Ressourcen eigentlich ab? Wenn Pacemaker den Dienst MySQL starten soll, ruft das Programm nicht »/usr/sbin/mysqld« mit den passenden Parametern auf. Stattdessen bedient er sich einer eigenen Shell-basierten API. Außerdem verwendet Pacemaker einige Wasserträger, die ihm das Starten und Stoppen von Ressourcen abnehmen. Die Abbildung 2 zeigt, wie Dienste von Pacemaker gestartet werden.

(9)

Abbildung 2: Pacemaker startet eine Applikation via Cluster Resource Manager, Local Resource Manager und Resource Agent.

Pacemaker, der – einmal gestartet – in der Prozess-Tabelle als »crmd« erscheint, läuft auf jedem Clusterknoten. Zusätzlich dazu läuft ebenso auf jedem Clusterknoten der Dienst

»lrmd« , der »Local Resource Management Daemon« . Die einzige Aufgabe des LRMDs ist es, Befehle von Pacemaker auf der einen Seite entgegenzunehmen und im Anschluss Shell- Skripte aufzurufen, um den von Pacemaker gewünschten Vorgang durchzuführen.

Diese Shell-Skripte nennen sich im Cluster-Jargon »Resource Agents« . Sie sind dafür verantwortlich, das passende Binary mit den konfigurierten Parametern aufzurufen.

Pacemaker unterstützt momentan drei Arten eben dieser Resource Agents: Zum einen Heartbeat-1-kompatible Agents, die allerdings als veraltet gelten, außerdem unterstützt es LSB-Agents, die gemeinhin auch als Init Scripts bezeichnet werden und schließlich gibt es noch die Königsklasse der Resource Agents: OCF-basierte Agents (Abbildung 3). Sie

verwenden einen eigenen Standard, der speziell für die Benutzung im Cluster gestaltet worden ist. Grundsätzlich gilt: Damit ein Skript in Pacemaker als Resource-Agent eingesetzt werden kann, muss es mindestens die Parameter »start« , »stop« und »monitor« kennen. Vorsicht ist auf Debian-Systemen geboten, denn viele Init-Skripte bei Debian kennen das »monitor« - Argument nicht.

Abbildung 3: Die OCF-Resource-Agents liegen typischerweise im Ordner

OCF-Resource-Agents weisen im Gegensatz zu den beiden anderen Gruppen eine Besonderheit auf, denn sie gehören jeweils zu einem eigenen »Provider« , sind also

nochmals in Gruppen aufgeteilt. Der DRBD-Resource-Agent kommt vom Provider »linbit« , der Resource-Agent für das Mounten von Dateisystemen kommt vom Anbieter

»heartbeat« . Die Anbieter der am häufigsten genutzten Resource Agents werden schnell geläufig. Und das ist gut so – wer regelmäßig Pacemaker-Cluster administriert, sollte sich jedenfalls die Namen der drei Kategorien sowie die Bezeichnung der wichtigsten OCF Resource Agents sehr gut merken.

(10)

Kommunikationspfade

Ein abschließendes Wort zur Cluster-Konfiguration – grundsätzlich gilt: Die Knoten eines Clusters sollten redundant miteinander kommunizieren können, also mindestens zwei voneinander unabhängige Kommunikationspfade zur Verfügung haben. Falls ein

Kommunikationspfad stirbt, steht der andere noch immer zur Verfügung. Sowohl Heartbeat als auch Corosync unterstützen Setups mit zwei Kommunikationspfaden. Achten Sie darauf, dass bei mindestens einem Kommunikationspfad eine direkte Verbindung zwischen den zwei Clusterknoten existiert – also eine, die nicht durch Switches geht. Wenn DRBD im Cluster zum Einsatz kommt, kann der zweite Pfad auch einen eventuellen Back-to-Back-Link verwenden.

Ressourcen

Zentral ist im Pacemaker-Kontext der Begriff der Ressource. Er wird einem im Cluster- Kontext immer wieder begegnen. Er meint nichts anderes als einen Dienst, der von Pacemaker verwaltet wird. Es kann sich also um eine DRBD-Ressource handeln, um eine MySQL-Instanz oder auch um eine IP-Adresse.

Pacemaker selbst ist der Ressourcen-Manager – aber wie wickelt er das Management von Ressourcen eigentlich ab? Wenn Pacemaker den Dienst MySQL starten soll, ruft das Programm nicht »/usr/sbin/mysqld« mit den passenden Parametern auf. Stattdessen bedient er sich einer eigenen Shell-basierten API. Außerdem verwendet Pacemaker einige Wasserträger, die ihm das Starten und Stoppen von Ressourcen abnehmen. Die Abbildung 2 zeigt, wie Dienste von Pacemaker gestartet werden.

Abbildung 2: Pacemaker startet eine Applikation via Cluster Resource Manager, Local Resource Manager und Resource Agent.

Pacemaker, der – einmal gestartet – in der Prozess-Tabelle als »crmd« erscheint, läuft auf jedem Clusterknoten. Zusätzlich dazu läuft ebenso auf jedem Clusterknoten der Dienst

»lrmd« , der »Local Resource Management Daemon« . Die einzige Aufgabe des LRMDs ist es, Befehle von Pacemaker auf der einen Seite entgegenzunehmen und im Anschluss Shell- Skripte aufzurufen, um den von Pacemaker gewünschten Vorgang durchzuführen.

Diese Shell-Skripte nennen sich im Cluster-Jargon »Resource Agents« . Sie sind dafür verantwortlich, das passende Binary mit den konfigurierten Parametern aufzurufen.

Pacemaker unterstützt momentan drei Arten eben dieser Resource Agents: Zum einen Heartbeat-1-kompatible Agents, die allerdings als veraltet gelten, außerdem unterstützt es

(11)

LSB-Agents, die gemeinhin auch als Init Scripts bezeichnet werden und schließlich gibt es noch die Königsklasse der Resource Agents: OCF-basierte Agents (Abbildung 3). Sie

verwenden einen eigenen Standard, der speziell für die Benutzung im Cluster gestaltet worden ist. Grundsätzlich gilt: Damit ein Skript in Pacemaker als Resource-Agent eingesetzt werden kann, muss es mindestens die Parameter »start« , »stop« und »monitor« kennen. Vorsicht ist auf Debian-Systemen geboten, denn viele Init-Skripte bei Debian kennen das »monitor« - Argument nicht.

Abbildung 3: Die OCF-Resource-Agents liegen typischerweise im Ordner

OCF-Resource-Agents weisen im Gegensatz zu den beiden anderen Gruppen eine Besonderheit auf, denn sie gehören jeweils zu einem eigenen »Provider« , sind also

nochmals in Gruppen aufgeteilt. Der DRBD-Resource-Agent kommt vom Provider »linbit« , der Resource-Agent für das Mounten von Dateisystemen kommt vom Anbieter

»heartbeat« . Die Anbieter der am häufigsten genutzten Resource Agents werden schnell geläufig. Und das ist gut so – wer regelmäßig Pacemaker-Cluster administriert, sollte sich jedenfalls die Namen der drei Kategorien sowie die Bezeichnung der wichtigsten OCF Resource Agents sehr gut merken.

Stonith und das Quorum

Ein Zwei-Knoten-Cluster wie im Beispiel leidet unter einem Problem, das sich auf das sogenannte Quorum bezieht. Das Quorum im Cluster-Kontext ist die Zahl der Clusterknoten, die mindestens vorhanden sein müssen, damit der Cluster-Manager den Cluster für funktional hält. Im Normalfall existieren zwei Knoten, und ein Quorum ist gegeben. Fällt allerdings ein Knoten aus, wäre kein Quorum mehr da. Pacemaker würde in der Standardkonfiguration alle Ressourcen anhalten und auf ein neues Quorum warten. Der Effekt ist freilich ungewollt.

Deshalb gilt es, bei einem frischen Pacemaker-Cluster diesen Effekt abzustellen.

Ein entsprechender »property« -Eintrag existiert; er heißt »no-quorum-policy« . Der nötige Wert ist »ignore« . Er lässt sich mithilfe der CRM-Shell setzen: Mittels »crm configure« landet man direkt im Konfigurationsmodul von Pacemaker; der passende Befehl lautet danach

» property no-quorum-policy="ignore"« . Übrigens: Die CRM-Shell unterstützt die automatische Komplettierung mittels [TAB] – hinter »no-quorum-policy=« hätte die CRM- Shell mit [TAB] beispielsweise alle möglichen Parameter aufgelistet, die für diesen

Konfigurationswert vorhanden sind.

Für das Beispiel ist eine zweite Konfigurationsänderung notwendig, die sich auf STONITH bezieht. STONITH heißt »Shoot The Other Node In The Head« ; es handelt sich um einen Fencing-Mechanismus, der es Pacemaker auf einem Knoten des Clusters erlaubt, den anderen Knoten neu zu starten, sollte dieser Probleme verursachen. STONITH ist insbesondere im Kontext von Datensicherheit wichtig, weil sie verhindert, dass mehrere Knoten zeitgleich zum Beispiel dieselben Platten mounten. Dafür wird das konkurrierende System gewaltsam

angehalten,

(12)

Die Technik wird üblicherweise mittels IPMI- oder ILO-Karten realisiert; aber auch andere Varianten existieren. In einem 2-Knoten-Cluster ist STONITH nicht zwingend notwendig – gerade dann nicht, wenn die Cluster-Knoten mehrere und voneinander unabhängige

Kommunikationspfade haben. Im Beispiel bleibt es daher deaktiviert. Das geht mit

»property stonith-enabled="false"« – ebenfalls im »configure« -Menü der CRM- Shell.

Die Änderung der Quorum-Policy sowie der STONITH-Funktion sind schließlich in den Cluster-Manager mittels »commit« zu übermitteln – das gilt für alle Änderungen, die wie beschrieben im »crm configure« -Menü der Shell ausgeführt werden.

Die erste Ressource

Grundsätzlich ist Pacemaker jetzt einsatzbereit – Gelegenheit, die erste Ressource in die Clusterkonfiguration zu übernehmen. Einzelne Ressourcen sind in Pacemaker stets

»primitive« -Ressourcen; der Befehl, um sie in die CIB einzubauen, heißt genauso und gehört zum »configure« -Menü der CRM-Shell. Er kennt verschiedene Parameter und Optionen. Grundsätzlich hat er folgende Syntax:

primitive Name_der_Ressource RA-Klasse[:Provider]: Name-des-RA params Parameter

• Name der Ressource ist eine frei wählbare Zeichenkette. Die komplette Bezeichnung des Ressource-Agents mag umständlich wirken, ist aber notwendig, um OCF-Agents

entsprechend abbilden zu können.

• RA-Klasse kann derzeit entsprechend der Erklärung weiter oben entweder »heartbeat« ,

»lsb« oder »ocf« sein.

• Provider kommt nur bei OCF-Agents zum Einsatz und bezeichnet den Provider, der zu einem OCF-Agent gehört – die eckigen Klammern sind in diesem Falle wegzulassen.

• Name des RA ist selbsterklärend.

• Das Schlüsselwort »params« legt Parameter fest, die sich auf die Konfiguration des Resource Agents beziehen.

[Tab] führt zu einer Übersicht aller Parameter, die der jeweilige Ressource-Agent unterstützt.

Auch bei der Angabe des RAs ist es übrigens für jedes der drei Felder möglich, sich mit [Tab]

eine Liste aller verfügbaren Einträge anzeigen zu lassen. Das hilft, falls der Name eines RAs nicht oder nur ungefähr bekannt ist.

Ein praktisches Beispiel: Pacemaker soll sich um die Verwaltung einer IP-Adresse kümmern.

Der entsprechende Ressource-Agent dafür heißt »IPaddr2« ; er ist ein OCF-Resource Agent vom Provider »heartbeat« und benötigt mindestens zwei Parameter – die eigentliche IP- Adresse und die Netmask dieser IP. Die passende Konfigurationszeile Zeile könnte so aussehen:

primitive p_ip1 ocf:heartbeat:IPaddr2 params ip=192.168.0.10 cidr_netmask=24

Diese Konfigurationszeile führt dazu, dass Pacemaker im Falle eines Failovers die IP auf dem jeweils verbliebenen Cluster-Knoten mit genau diesen Parametern starten würde. Noch nicht abgedeckt ist im Beispiel die Situation, dass die IP-Adresse aus irgendwelchen Gründen von dem System, auf dem sie läuft, verschwindet. Es ist deshalb notwendig, die Ressource- Definition um eine »Operation« zu erweitern – nämlich um eine Monitoring-Operation. In

(13)

Ressource-Definitionen leiten sich Operationen mit dem Schlüsselwort »op« ein. Anders als bei den Parametern, wo nur einmal »params« steht, ist jede Operation mit »op« einzuleiten.

Um dafür zu sorgen, dass Pacemaker in einem Interval von 15 Sekunden überprüft, ob die IP noch existiert, reicht es, am Ende der Zeile oben »op monitor interval=15s« einzufügen.

Das sorgt für Ressourcen-Monitoring. Nach dem Hinzufügen einer Primitive-Ressource schaltet Pacemaker die neue Konfiguration durch »commit« scharf.

Statusinformationen über den Cluster sind für den Administrator wichtig. Mit »crm_mon« (Abbildung 4) steht ein Werkzeug zur Verfügung, um sich schnell einen Überblick über den Zustand des Systems zu verschaffen (Abbildung 5). »^{crm_mon -1}« zeigt den gegenwärtigen Zustand an und beendet sich danach wieder. Dagegen führt »crm_mon« zu einer Cluster- Konsole, die jeder neue Event aktualisiert. Erweitert um die Parameter »-rf« zeigt der CRM- Monitor auch Fehler sowie deaktivierte Ressourcen an.

Abbildung 5: Mittels des Werkzeugs

Abbildung 4: crm_mon Im Cluster aufräumen

So wichtig wie das Hinzufügen von Ressourcen ist das Aufräumen des Clusters, wenn beim Hinzufügen etwas schiefgegangen ist. Wenn nämlich schon der erste Start einer Ressource auf einem Knoten fehlschlägt, unternimmt Pacemaker keine weiteren Versuche. Dann ist es nötig, die jeweilige Ressource mittels »crm resource cleanup Name« von der Shell aus

aufzuräumen. Pacemaker setzt dann den »failcount« auf » « , vergisst also quasi, dass die Ressource nicht gestartet werden konnte. Ob das Aufräumen funktioniert hat, ist wiederum mittels »crm_mon -rf« herauszufinden.

(14)

Was kommt

Dieser einleitende Artikel kratzte nur an der Oberfläche dessen, was Pacemaker leisten kann.

Die nächsten Teile der HA-Serie beschäftigen sich mit der Integration von DRBD-Ressourcen in Pacemaker und mit Abhängigkeiten zwischen einzelnen Ressourcen. Der dritte Artikel wird die Schaffung eines hochverfügbaren MySQL-Servers unter Verwendung von DRBD und Pacemaker beispielhaft demonstrieren. Der vierte Artikel beschäftigt sich mit dem Thema Virtualisierung im Clusterkontext.

(15)

BitWorld

bitworld.de. Abgerufen am 03. 06 2013 von

http://www.bitworld.de/index.php/grundlagen/soap

Simple Object Access Protocol (SOAP) Grundlagen - SOAP

Geschrieben von: Christian Jänicke Samstag, 23. Januar 2010

WebServices verwenden das Simple Object Access Protocol (SOAP) als

Kommunktationsprotokoll. SOAP ist ein auf XML basierendes Format, um Nachrichten zu versenden und ist sowohl Plattform- wie auch Sprachunabhängig.

Aufbau einer SOAP-Nachricht

Eine SOAP-Nachricht ist eine einfache XML-Struktur, die folgende Elemente enthält bzw.

enthalten kann:

• ein Envelope Element

• ein Header Element (optional)

• ein Body Element mit optionalem Fault Element

Desweiteren unterliegen SOAP-Nachrichten bestimmten Einschränkungen, die im Folgenden zusammengefasst sind:

• Jede SOAP-Nachricht muss ein gültiges XML-Dokument sein

• Alle SOAP-Elemente müssen in folgendem Namespace deklariert sein:

http://www.w3.org/2001/12/soap-envelope/

• Alle SOAP-Datentypen müssen in folgendem Namensraum deklariert sein:

http://www.w3.org/2001/12/soap-encoding/

• In einer SOAP-Nachricht darf keine Dokumenttyp-Deklaration (DTD) enthalten sein

• In einer SOAP-Nachricht dürfen keine XML Processing Instructions enthalten sein Beispiel:

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding/">

<soap:Header>

...

</soap:Header>

<soap:Body>

...

</soap:Body>

</soap:Envelope>

(16)

Element: Envelope

Das Envelope Element ist das Wurzelelement einer SOAP-Nachricht und darf nur einmal pro Nachricht definiert werden. Jede SOAP-Nachricht muss ein Envelope Element enthalten.

Element: Header

Das Header Element ist optional und muss, sofern angegeben, das erste Element innerhalb des Envelope Elements sein. Im Header Element können beliebige Einträge abgelegt werden.

Typischer weise enthalten Header Elemente Transaktionsdaten, Zugriffsdaten (Benutzername, Kennwort) oder Routinginformationen. Die Header Einträge müssen durch einen eigenen Namensraum (Namespace) deklariert werden.

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding/"

xmlns:myapp="http://www.bitworld.de/myapp/">

<soap:Header>

<myapp:Authentication>

<myapp:Username>chris</myapp:Username>

<myapp:Password>encrypted</myapp:Password>

</myapp:Authentication>

</soap:Header>

<soap:Body>

...

</soap:Body>

In dem Header Element können die Einträge durch zusätzliche SOAP-Attribute spezifiziert werden.

Attribut (Header Eintrag): actor

Eine SOAP-Nachricht kannüber verschiedene Knotenpunkte (Server) weitergereicht werden.

Mit den Attribut actor kann ein Header Eintrag für einen bestimmten Knotenpunkt zur Auswertung markiert werden, d.h. nur der angegebene Knoten darf den Eintrag auswerten, alle anderen Knoten müssen diesen ignorieren. Der Attributwert ist entweder der URI des Knotenpunkttes, für den der Eintrag bestimmt ist, oder der reserviert URI

http://schemas.xmlsoap.org/soap/action/next , welcher den aktuellen Knoten zur Auswertung des Header Eintrag auffordert.

Hat der aktuelle Knoten den Header Eintrag ausgeführt und ist er nicht der Zielknoten der SOAP-Nachricht, so werden alle für den aktuellen Knoten bestimmten Header Einträge aus der Nachricht entfernt und die Nachricht wird an den nächsten Knoten weitergeleitet.

<soap:Header>

<myapp:Authentication soap:actor="http://www.bitworld.de/auth/">

<myapp:Username>chris</myapp:Username>

<myapp:Password>encrypted</myapp:Password>

(17)

</myapp:Authentication>

</soap:Header>

<soap:Body>

...

</soap:Body>

Attribut (Header Eintrag): mustUnderstand

Mit dem Attribut mustUnderstand kann ein Header Eintrag als zwingend notwendig gekennzeichnet werden. Der Empfänger der SOAP-Nachricht muss diesen Header Eintrag auswerten können, sonst muss der Empfänger die Nachricht ablehnen. Ein Wert von 1 kennzeichnet den Eintrag als zwingend notwendig, ein Wert von 0 kennzeichnet den Eintrag als optional.

Attribut (Header Eintrag): encodingStyle

Das Attribut encodingstyle definiert die Datentypen, die für den angegebenen Header Eintrag gültig sind.

Element: Body

In dem Body Element ist die eigentliche Nachricht enthalten. Alle Elemente der Nachricht sollten durch einen eigenen Namensraum gekennzeichnet werden.

<soap:Body>

<myapp:SayHello>

<myapp:Name>Christian</myapp:Name>

</myapp:SayHello>

</soap:Body>

Element: Fault

Es gibt ein spezielle Element, welches im Body angegeben werden kann: das Fault Element.

Fault Elemente kennzeichnen Fehler, die bei der Verarbeitung der Nachricht aufgetreten sind.

Folglich werden Fault Elementüberlicherweise in Antwort-Nachrichten angegeben, um den Sender der Nachrichtüber aufgetretene Fehler zu informieren.

Das Fault Element verfügtüber vier weitere Unterelemente:

Element (Fault): faultcode

Das Element faultcode gibt den Fehlercode des Fehlers an, der Aufgetreten ist. Es gibt vier mögliche Wert:

VersionMismatch

Zeigt an, dass für das Envelope Element ein ungültiger Namensraum

(18)

angegeben wurde. (Der Namensraum definiert die SOAP Version)

MustUnderstand Ein mit dem Attribut mustUnderstand gekennzeichneter Header Eintrag kann von dem aktuellen Knoten nicht verarbeitet werden.

Client Die SOAP-Nachricht konnte nicht verarbeitet werden.

Server Es ist ein interner Server-Fehler aufgetreten.

Element (Fault): faultstring

In dem Element faultstring kann eine Fehlerbeschreibung angegeben werden.

Element (Fault): faultactor

Das Element faultactor enthält die URI des Knotens, bei dem der Fehler aufgetreten ist.

Element (Fault): detail

In dem Element ^detail können zusätzliche Informationen zum Fehler angegeben werden (auch in XML-Form).

xmlns:myserver="http://www.bitworld.de/myserver/">

<soap:Body>

<soap:Fault>

<soap:faultcode>Server<soap:/faultcode>

<soap:faultstring>Too few parameters<soap:/faultstring>

<soap:detail>

<myserver:details>

<myserver:message>Please enter your name</myserver:message>

</myserver:details>

</soap:detail>

</soap:Fault>

</soap:Body>

(19)

BSI

BSI.Bund.de. Abgerufen am 04. 06 2013 von

https://www.bsi.bund.de/DE/Themen/SmartMeter/Schutzprofil_Security/securit y_module_node.html

Schutzprofil für das Sicherheitsmodul eines Smart Meter Gateways (BSI-CC- PP-0077)

In einem intelligenten Messsystem bildet das Smart Meter Gateway (SMGW) die zentrale Kommunikationseinheit, die Messdaten von Zählern empfängt, speichert und diese für autorisierte Marktteilnehmer aufbereitet. Das SMGW ist damit eine wesentliche Komponente in den Netzendpunkten des intelligenten Energienetzes. Durch seine Kernaufgabe des

Messdatenversands werden besondere Anforderungen hinsichtlich der Sicherheit an das SMGW gestellt. Insbesondere werden die Kommunikationsflüsse zwischen dem SMGWund den übrigen Komponenten und beteiligten Parteien des Smart-Metering-Systems auf

kryptographischem Wege abgesichert. Das SMGW bedient sich hierzu eines Sicherheitsmoduls, das zum einen als sicherer Speicher für das dazu erforderliche Schlüsselmaterial dient und zum anderen für das SMGW selbst die Kernroutinen für Signaturerstellung und -prüfung, Schlüsselgenerierung, Schlüsselaushandlung sowie Zufallszahlengenerierung bereitstellt.

Um die Sicherheitsfunktionalität des Sicherheitsmoduls geeignet zu erfassen und festzuschreiben, wurde durch das BSI ein entsprechendes Schutzprofil für das Sicherheitsmodul erstellt.

(20)

Cassandra

Apache, cassandra.apache.org. Abgerufen am 02. 07 2013 von http://cassandra.apache.org/

The Apache Cassandra database is the right choice when you need scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission- critical data. Cassandra's support for replicating across multiple datacenters is best-in-class, providing lower latency for your users and the peace of mind of knowing that you can survive regional outages.

Cassandra's data model offers the convenience of column indexes with the performance of log-structured updates, strong support for denormalization and materialized views, and powerful built-in caching.

(21)

Cryptas

cryptas.com. Abgerufen am 25. 06 2013 von http://www.cryptas.com/cryptas/wissen- unterstuetzung/digitale-signatur/typen-digitaler-signaturen.html

Digitale Signatur

Eine digitale Signatur als Analogon zur handschriftlichen Unterschrift sollte einige Anforderungen erfüllen. Anforderungen an die handschriftliche Unterschrift sind weder gesetzlich festgelegt, noch einheitlich verwendet werden, doch wird zumeist zur Authentizität und Verbindlichkeit auch

• Verifizierbarkeit: alle Personen müssen in der Lage sein, die Echtheit der Unterschrift zu prüfen; und

• Nachrichtenabhängigkeit: die Unterschrift muss sich auf eine bestimmte Nachricht beziehen und von dieser funktional abhängen,

gefordert, welche handschriftliche Unterschriften nur schwer, z.B. mit Unterschriftenblättern, sicherzustellen ist. Mehr dazu in rechtliche Anforderungen an digitale Signaturen. Digitale Signaturen erfüllen diese Eigenschaften viel besser, man beachte aber, dass digitale

Signaturen keine Vertraulichkeit sicherstellen.

Alle Versuche mit symmetrischen Verfahren eine digitale Signatur zu konstruieren führen dazu, dass eine dritte vertrauenswürdige Partei herangezogen werden muss, die an der Erzeugung und Überprüfung beteiligt werden muss. Asymmetrische Verfahren bieten daher Vorteile. Die Authentizität und Verbindlichkeit wird so durch die Verwendung eines privaten Schlüssel erreicht, die Verifizierbarkeit mit dem öffentlichen Schlüssel, für die

Nachrichtenabhängigkeit werden Hash-Funktionen oder die Verschlüsselung mit dem privaten Schlüssel herangezogen. Grundsätzlich gibt es zwei Arten von digitalen Unterschriften.

• Digital signature giving message recovery: Die Digital zu unterschreibende Nachricht wird in Blöcke geteilt und jeder Block wird einzeln mit dem Schlüssel des Unterzeichners signiert.

Eine kryptographische Verkettung oder eine (mitsignierte) Prüfsumme ist empfehlenswert.

• Digital signature with appendix: Aus der zu unterschreibenden Nachricht wird ein

kryptographischer Hash bestimmter Länge gebildet, und nur dieses wird mit dem privaten Schlüssel des Unterzeichners verschlüsselt, bzw. signiert - die üblichere Variante. Zur

Überprüfung wird aus der Nachricht wiederum der Hash gebildet und mit dem übertragenen signierten Hash-Wert verglichen.

Viel wichtiger als bei handschriftlichen Signaturen gehört zur Überprüfbarkeit der Gültigkeit von digitalen Signaturen auch der Erstellungszeitpunkt der digitalen Signatur, diese können mit Zeitstempeldiensten realisiert werden. Auch dem Umstand, dass solche Unterschriften "

ablaufen " muss durch Nachsignierung Rechnung getragen werden.

Wenn andere Sicherheitsziele erreicht werden sollen können besondere Formen von digitalen Signaturen, wie blinde oder duale Signaturen eingesetzt werden.

(22)

Digitale Signatur digital Signature with appendix

Überprüfung einer digitalen Signatur

Die Verifikation einer Digitalen Signatur besteht aus der eigentlichen Signaturprüfung und der Prüfung auf die Gültigkeit des signierenden Zertifikates. Bei der Signaturprüfung wird mit dem öffentlichen Schlüssel, dem man aus dem Zertifikat kennt, der verschlüsselte Hash-Wert entschlüsselt. Über die signierten Daten wird ebenfalls ein Hash-Wert gerechnet und mit dem entschlüsselten Wert verglichen. Sind diese Werte identisch, ist klargestellt, dass die Daten unverändert sind und der, zum öffentlichen Schlüssel gehörende, private Schlüssel für die Signatur verwendet wurde.

Die Identität und die Gültigkeit des Schlüsselpaares werden mit Hilfe der Trusted Third Party, der Zertifizierungsstelle, überprüft. Anhand des Widerrufsdienstes wird die Gültigkeit des Zertifikates geprüft und der Zertifizierungspfad bis zu einem Stammzertifikat aufgebaut. Die Zertifikate im Pfad werden natürlich ebenfalls einer Widerrufsprüfung unterzogen. Die Prüfung des Zertifizierungspfades ist eine Kaskade weiterer Signatur und

Widerrufsprüfungen.

Zusätzlich ist auch die Prüfung weiterer Eigenschaften der Zertifikate im Zertifizierungspfad sinnvoll, z.B. ist anhand der "Basic Constraints" zu überprüfen ob mit diesem Zertifikat weitere Zertifikate ausgestellt werden dürfen.

Formate für Digitale Signaturen

Die Datenstruktur der digitalen Signatur benötigt ein Format, das eventuell auch die originalen Daten aufnehmen kann, oder eine Referenz darauf beinhaltet.

PKCS#7 ist ein Standard der weit genutzt wurde. Heutzutage setzt man auf XML DigSig.

XML Digital Signature

Extensible Markup Language (XML) ist als flexibles, hoch erweiterbares Textformat zum Datentransport, prädestiniert für den Transport von komplexen Datenstrukturen.

XML Encryption und XML Signature beschreiben Anforderungen für Verschlüsselung und Signatur von XML-Dokumenten sowie die Repräsentation dieser Daten (Chiffre, Signatur) durch eine XML Dokument. XKMS (XML Key Management Specification) beschäftigt sich

(23)

mit dem Management von Informationen über kryptographische Schlüssel mittels Webservices.

Die gemeinsam von IETF und W3C gestartete Normung einer XML Signatur Syntax und Verarbeitungsregeln sind in den XML Signature Requirements ist im IETF RFC 2807 oder http://www.w3.org/Signature/ veröffentlicht.

Charakteristisch für eine XML Signatur ist die Möglichkeit nur Teile eines XML Dokuments zu signieren, was Flexibilität hinsichtlich mehrerer Signaturen bei der Erstellung, bzw. auch bei einer etwaigen Weiterverarbeitung gibt. Eine XML Signatur kann natürlich über

unterschiedliche Daten (XML, HTML, Binaries,...) gelegt werden.

Eine XML Signatur ist ein wohldefiniertes XML Dokument, wobei die Signatur über die kanonische Form eines "Signature Manifest" gerechnet wird.

XML Signatur Erstellung

1. Das Signatur-Manifest, die Liste der zu signierenden Daten, wird gesammelt, bzw. über URIs referenziert.

2. Über die zu signierenden Ressourcen wird einzeln der Hash-Wert gerechnet. Der Wert und die Metainformationen (Hash-Algorithmus) werden in "Reference"-Elementen

zusammengefasst.

3. Die "Reference"-Elemente werden zu einem "SignedInfo" Element zusammengefasst, das zusätzlich Elemente über das Kanonisierungsverfahren und verwendete Signaturalgorithmus beinhaltet.

4. Über das SignedInfo-Element wird ein Hash-Wert gerechnet, signiert und als Wert in das

"SignatureValue" Element übernommen.

5. Schlüsselinformationen, sprich Zertifikat und andere Informationen, werden in ein

"KeyInfo"-Element gelegt.

6. "SignedInfo", "SignatureValue" und "KeyInfo" werden in ein Signaturelement platziert, und so die XML-Signatur darstellt.

Blinde Signaturen

Im Bereich des digitalen Geldes und Systemen zu Online Wahlen kommen oft Blinde Signaturen zum Einsatz um das Sicherheitsziel der Anonymität zu erreichen.

Blinde Signaturen haben die grundlegende Eigenschaft, dass der Unterschreibende nicht sieht, was er signiert. Im Grunde wird nicht der Inhalt unterschrieben, sondern die Vorlage durch eine bestimmte Partei. Einerseits soll durch eine Unterschrift des Herausgebers von digitalem Geld die Gültigkeit des Zahlungsmittels bewiesen werden können, andererseits soll die Verwendung des Zahlungsmittels nicht verfolgt werden können. Grundsätzlich unterscheidet man mehrere Typen von blinden Unterschriften obwohl man im Allgemeinen stark blinde Signaturen meint, und nicht verdeckte, oder schwach blinde Signaturen:

stark blinde Signaturen: Auch, wenn der Unterzeichner ein Dokument inklusive seiner

(24)

Unterschrift sieht, kann er es dem Besitzer nicht zuordnen. Durch Verwendung von

"Blendfaktoren" bei der Erstellung bzw. Ausgabe, kann der Ausgebende von digitalen Werteinheiten oder Wahlzetteln später erkennen, dass es sich um gültige Geldeinheiten, oder Wahlzettel handelt, aber nicht an wen er diese ursprünglich ausgegeben hat.

Duale Signaturen

Duale Signaturen sind (oder waren), von SET (Secure Electronic Transaction) eingeführte, kryptographische Verfahren, ähnlich den digitalen Signaturen. Sie dienen dazu, zwei Nachrichten so miteinander zu verbinden, dass der Empfänger nur eine der beiden Nachrichten kennen muss, um die Authentizität des Senders überprüfen zu können.

Bei SET wird so die Information über die Bestellung und die Kreditkarteninformation verknüpft, indem über beide Informationen ein eigener Hash-Wert gerechnet wird und dann auf die Verbindung dieser beiden nochmals ein ("dualer") Hash-Wert gerechnet wird, der sodann mit dem privaten Schlüssel des Bestellenden verschlüsselt wird - "dual signiert".

Diese Signatur wird an beide einzelnen Nachrichten angefügt.

Eine dual signierte Nachricht enthält zur Überprüfung der dualen Signatur, zusätzlich zur übertragenen Information den Hash-Wert des anderen Teils. Damit kann der Prüfende den

"duale" Hash-Wert erstellen, der mit dem signierten Hash-Wert verglichen werden kann.

Fazit: Der Händler kann keine Kreditkarteninformation einsehen, da er nur einen Hash-Wert davon erhält, die Bank sieht keine Bestellung, trotzdem sind beide Informationen verbunden signiert.

(25)

CUBRID

cubrid.org. Abgerufen am 20. 06 2013 von

http://www.cubrid.org/manual/91/en/shard.html

Database Sharding Horizontal partitioning

Horizontal partition is a design to partition the data for which schema is identical, based on the row, into multiple tables and store them. For example, 'User Table' with identical schema can be divided into 'User Table #0' in which users less than 13 years are stored and 'User Table #1' in which users 13 or greater than 13 years old.

Database sharding

Database sharding is to store data into physically separate databases through horizontal partitioning and to retrieve them. For example, it is a method to store users less than 13 years old in database 0 and store users 13 or greater than 13 years old in database 1 when 'User Table' is located through multiple database. In addition to performance, database sharding is used to distribute and save large data which cannot be saved into one database instance.

Each partitioned database is called a shard or database shard.

(26)

CUBRID SHARD

The CUBRID SHARD is middleware for database sharding and its characteristics are as follows:

• Middleware that is used to minimize changes in existing applications, allowing access to transparently sharded data by using Java Database Connectivity (JDBC), a popular choice, or CUBRID C Interface (CCI), which is CUBRID C API.

• In this function, a hint may be added to an existing query to indicate a shard in which the query would be executed.

• It can be configured on backend shard DBs such as MySQL, as well as CUBRID.

• It guarantees the unique characteristics of certain transactions.

More details on each characteristic will be described in the next chapter.

CUBRID SHARD Terminologies

The terminologies used to describe CUBRID SHARD are as follows:

• shard DB : A database that includes a split table and data and processes user requests

• shard metadata : Configuration information for the operation of a CUBRID SHARD. It analyzes the requested query and includes information to select a shard DB which will execute a query and to create a database session with the shard DB.

• shard key (column) : A column used as an identifier to select a shard in the sharding table

• shard key data : A shard key value that corresponds to the hint to identify the shard from the query

• shard ID : An identifier to identify a shard DB

(27)

• shard proxy : A CUBRID middleware process that analyzes hints included in user queries and sends requests to a shard DB which will process the query, based on the analyzed hint and the shard metadata

(28)

Curtalo

curtalo.de. Abgerufen am 02. 07 2013 von

http://www.curtalo.de/workshop/von-wie-apache-bis-wie-zookeeper/

Apache: Die Apache Software Foundation (ASF) ist eine Non-Profit-Organisation, die 1999 aus der US-amerikanischen Apache Group ausgegründet wurde. Das Ziel der ASF ist die Förderung, Weiterentwicklung und Standardisierung von Software-Projekten. In diesem Sinne hat sie es sich auch zum Ziel gesetzt, die Hadoop-Plattform und deren Software- Bibliotheken weiter auszubauen.

Avro: Avro ist ebenfalls ein Apache-Projekt, das als Teil von Hadoop entwickelt wurde. Das Framework dient der Serialisierung von Daten und unterstützt Remote Procedure Calls, also den Aufruf von Funktionen zwischen unterschiedlichen Systemen. Avro ist ein wichtiger Hadoop-Bestandteil, der für ein schnelles Processing zwischen verteilten Systemen essentiell ist.

Big Data: Der Begriff Big Data beschreibt in erster Linie ein Phänomen: den exponentiellen Anstieg des global existierenden Datenvolumens. Dabei spielt es keine Rolle, aus welchen Quellen diese Daten stammen – wichtig ist lediglich, dass sich die verfügbaren Informationen rasend vermehren und ihr Potenzial mit klassischen Lösungen kaum ausgeschöpft werden kann. Gängige Datenbank-, Datawarehousing- und Analysesysteme stoßen aufgrund der reinen Masse, aber auch aufgrund der Beschaffenheit der Daten an ihre Grenzen.

Leistungsstarke Technologien zur Verarbeitung von Big Data werden deshalb unter anderem dazu in der Lage sein müssen, auch unstrukturierte Daten zu erfassen. Frameworks wie Hadoop basieren auf dem Prinzip verteilter Rechenoperationen und machen damit große Datenmengen handhabbar und produktiv nutzbar. Der Computerworld-Journalist Jaikumar Vijayan weist in seinem Artikel „Moving beyond Hadoop for big data needs“ jedoch darauf hin, dass bei allem Potenzial von Hadoop schon heute nicht nur die reine Fähigkeit, große Datensätze zu verarbeiten, sondern zudem die Geschwindigkeit, mit der dieses geschieht, von Bedeutung ist.

Cascading: Cascading ist ein Java-basiertes Anwendungs-Framework zur Entwicklung von Data Analytics- und Data Management-Anwendungen auf Basis von Hadoop. Der Tech- Blogger Don Burnett hat eine Präsentation zum Thema „Hadoop and the Cascading Toolkit“

auf Youtube veröffenlicht – eine nette Zusammenfassung für alle, die sich schnell einen Überblick verschaffen wollen.

Cassandra: Apache Cassandra ist ein einfaches, verteiltes, NoSQL-

Datenbankverwaltungssystem für sehr große strukturierte Datenbanken. Es ist offen dokumentiert und als freie Software ebenfalls unter Apache-Lizenz erhältlich. Besondere Merkmale: Hohe Skalierbarkeit und Ausfallsicherheit.

CDH/CDH4: CDH steht für „Cloudera’s Distribution Including Apache Hadoop“ und ist nach Angaben von Cloudera die meist genutzte Hadoop-Lösung weltweit. Sie dient zur Bereitstellung großer Datenmengen und nutzt dabei sowohl die zentralen Elemente von Hadoop – also skalierbaren Speicher und eine verteilte Computing-Umgebung – als auch geschäftskritische Leistungsmerkmale wie Sicherheit, hohe Verfügbarkeit und die Integration mit bestehenden Hard- und Softwareumgebungen. CDH ist derzeit in Version 4 verfügbar.

(29)

Chukwa: Apache Chukwa ist ein Hadoop-Unterprojekt, das als Analysis- und Monitoring- System die Echtzeitüberwachung sehr großer, verteilter Systeme erlaubt. Eine sehr

anschauliche Erklärung für alle, die mehr wissen möchten, gibt es hier.

Distributed Computing: Der vermutlich bekannteste Vorreiter für verteilte Rechenprozesse ist SETI@home – mehr als 2,3 Millionen Computernutzer haben sich zum leistungsstärksten virtuellen Großrechner der Welt zusammengeschlossen. Und damit ist das Prinzip Distributed Computing letztlich auch erklärt: Verteiltes Rechnen oder auch Dezentralisiertes Rechnen ist eine Technik der Anwendungsprogrammierung, bei der die einzelnen Prozesse einer verteilten Anwendung ein gemeinsames Ergebnis berechnen – zum Beispiel zur Suche nach

außerirdischer Intelligenz. Dan Garcia von der University of California erklärt in einem Vorlesungsmitschnitt (Video) das Prinzip „Distributed Computing“ – interessant wird es ab Minute 13.

Doug Cutting: Schöpfer und Namensgeber von Hadoop, der das System nach dem

Kuschelelefanten seiner Tochter benannte. Doug Cutting ist außerdem Chairman der Apache Software Foundation und der Chefentwickler von Cloudera.

Cloudera: Cloudera ist die wohl renommierteste Software-Schmiede für Apache Hadoop- basierte Lösungen und Dienstleistungen. Inhaber ist der Hadoop-Schöpfer und ASF-

Vorsitzende Doug Cutting. Cloudera unterstützt die Apache Software Foundation sowohl mit finanziellen Mitteln als auch mit Manpower: Nach eigenen Angaben kommen über 50 Prozent der eigenen Entwicklungsleistungen der ASF zugute. In einem Interview mit Scott Swigart von der Open Source-Community PORT25 bezieht Amr Awadallah, CTO bei Cloudera, ausführlich Stellung zu allen relevanten Hadoop-Themen.

Eclipse: Eclipse ist eine beliebte Open Source-Entwicklungsplattform, die gerade in Hadoop- Umgebungen gerne von Entwicklern genutzt wird. Ein Beispiel für das Eclipse-Ecosystem ist BIRT, eine offene Business Intelligence- und Reporting-Lösung, über die sich auch Big Data visualisieren lässt.

Hadoop: Apache Hadoop ist ein freies, Java-basiertes Programmier-Framework, das die Verarbeitung sehr großer Datensätze in verteilten Rechenumgebungen unterstützt. Finanziert und verwaltet wird das Projekt von der gemeinnützig tätigen Apache Software Foundation (ASF). Die Erfassung und Nutzung von Big Data könnte aufgrund des immensen,

polystrukturierten Datenvolumens ohne Processing-Technologien wie Hadoop gar nicht verarbeitet werden – nur über verteilte Systeme, die Tausende von Verbindungspunkten (Hardware-Nodes) und Abertausende von Bytes vereint, werden ein rapider Datenverkehr und ein effektives Data Processing vermutlich überhaupt erst möglich sein. Einen guten Überblick über die Möglichkeiten von Hadoop liefert dieser Beitrag von BARC-Analyst Dr. Carsten Bange und Martin Lange, Global Leader Open Source Integration bei Talend.

Hama: Apache Hama ist ein reines BSP (Bulk Synchronous Parallel)-Framework, das auf HDFS aufsetzt und für massive, wissenschaftliche Rechenprozesse wie beispielsweise Matrix-, Graph- oder Netzwerk-Algorithmen gedacht ist.

HBase: Apache HBase ist eine skalierbare, spaltenorientierte Datenbank (ein so genannter Key Value Store), über die sich sehr große Datenmengen innerhalb eines Hadoop-Clusters verwalten lassen. Im Gegensatz zu Hive beispielsweise besteht mit HBase die Möglichkeit, Daten zu manipulieren. Deshalb ist das System besonders für volatile (also flüchtige) Daten geeignet, die in kurzen Abständen aufgefrischt oder verändert werden. Auch Realtime-

(30)

Abfragen mit minimalen Latenzzeiten können mit HBase gut umgesetzt werden. Eine grundlegende Einführung in das Thema HBase gibt es in diesem Video.

Hadoop Distributed File Systems (HDFS): Das verteilte Dateisystem HDFS ist eine der Kernkomponenten von Hadoop. HDFS zeichnet sich durch seine hohe Ausfallsicherheit aus und wurde für den Betrieb auf kostengünstiger Hardware entwickelt. Die zentralen Ziele von HDFS: eine schnelle Fehlererkennung, eine schnelle Wiederherstellung von Daten sowie die Verwaltung von großen Datenbeständen im Petabyte-Bereich. Die FH Köln hat die

entscheidenden Fakten zu HDFS im hauseigenen Online-Lexikon gut nachvollziehbar zusammengestellt.

Hive: Das Java-basierte Datawarehouse Apache Hive wurde ursprünglich von Google entwickelt, im Sommer 2008 stellte der Konzern das System jedoch der Open-Source- Gemeinde zur freien Weiterentwicklung zur Verfügung. Hive ergänzt Hadoop um Data- Warehouse-Funktionalitäten wie die Anfragesprache HQL und Indizes. HQL ist eine auf SQL basierende Abfragesprache und ermöglicht dem Entwickler somit die Verwendung einer SQL-ähnlichen Syntax. Hive lässt sich in HBase integrieren. Wer mehr über Hive und seine Unterschiede zu anderen Datenbanken erfahren möchte, erhält weitere Informationen im Online-Lexikon der Fachhochschule Köln.

Hortonworks: Das Unternehmen unter der Federführung von Eric Baldeschweiler ist 2011 aus dem Yahoo!-Team hervorgegangen, das sich maßgeblich an der Entwicklung von Hadoop beteiligt hat. Die Hortonworks Data Platform ist eine quelloffene, auf dem Hadoop-

Framework basierende Komplettlösung, die aufeinander abgestimmte Komponenten – von der Verarbeitung der Daten bis zum Monitoring der Cluster – umfasst.

Mahout: Apache Mahout ist eine freie, in Java geschriebene Programmbibliothek unter Apache-Lizenz, die für verteiltes, maschinelles Lernen und Data Mining angelegt wurde. Die Software setzt ebenfalls auf Hadoop auf. Eine “Mahout in 3 Minuten”-Einführung gibt es hier.

MapReduce: Das Programmierframework MapReduce wurde 2004 von Google eingeführt und trägt seitdem maßgeblich dazu bei, die parallele und verteilte Verarbeitung von Daten so effizient wie möglich zu gestalten. Das Prinzip in einfachen Worten: Die MapReduce-

Methode zerlegt eine Aufgabe in kleinste Teile, verteilt diese zur parallelen Verarbeitung auf möglichst viele Rechenknoten (mapping) und führt anschließend das Ergebnis zusammen (reduce). Ein kleines Programmierbeispiel für das Prinzip von MapReduce gibt es auf

ScienceBlogs. In einer Seminararbeit der Berliner Humboldt-Universität heißt es: „Die Stärke von MapReduce liegt in der Einführung einer neuen Abstraktionsebene, die die technisch komplexen Aspekte der parallelen Programmierung wie Last- und Datenverteilung oder Fehlertoleranz innerhalb eines Frameworks vor dem Benutzer verbirgt. Ein Benutzer, der gegen die Schnittstellen des Frameworks programmiert, muss sich nur noch mit der Frage

„Was soll berechnet werden?“ befassen und nicht mehr darauf konzentrieren, wie die Parallelverarbeitung läuft. Ein weiterer praktischer Vorteil von MapReduce ist die

Möglichkeit, handelsübliche Standard-Hardware zu verwenden. Die Einführung in das Thema MapReduce von Stefan Bethge und Astrid Rheinländer kann als PDF heruntergeladen

werden.

Pig: Apache Pig ist eine von Yahoo entwickelte Plattform zur Analyse großer Datenmengen, die 2007 in den Apache-Pool überging. Möglich ist die Analyse von Big Data durch eine einfache Skriptsprachen-Syntax, die Datenrelationen und deren Verarbeitung beschreibt. Pig-

(31)

Skripte werden automatisch in eine Anzahl Mapper- und Reducer-Prozesse des Hadoop- Frameworks übersetzt und ausgeführt. Auf diese Weise können Ad-hoc-Abfragen in großen Datenbeständen innerhalb einer Hadoop-Umgebung ausgeführt werden.

Wirtschaftsinformatiker an der Universität Stralsund haben einen Interessanten Vergleich zwischen Pig und Hive veröffentlicht.

Serialisierung (Serialization): Diese Technologie ist essentiell für ein schnelles Processing von großen Datenmengen. Bei der Serialisierung wird der Zustand einzelner Datenelemente, den sogenannten Objekten, zusammen mit all ihren Verknüpfungen in eine Folge von Bytes umgewandelt. Objekte können ganz konkret einen bestimmten, vorab definierten Datentyp (Klasse) beschreiben. Das kann so etwas Pragmatisches wie beispielsweise die Angabe einer Adresse in den einzelnen Elementen Straße, Hausnummer, Postleitzahl und Ort sein. Die Serialisierung solcher Datenobjekte hat zahlreiche Vorteile, da Objekteigenschaften mit dieser Methode nicht separat gespeichert werden müssen und trotzdem auch außerhalb ihres

Programmes weiterexistieren können. Diese Eigenschaften sind bei verteilten Systemen für ein effizientes Daten-Processing sehr wichtig. Eine ausführliche Erklärung bietet das Online- Lexikon IT-Wissen.

Yarn: Apache Yarn alias MapReduce 2.0 (MRv2) ist der Nachfolger der originalen

MapReduce-Version. YARN trennt Jobtracker, Ressourcenverwaltung sowie Job-Scheduling und -Monitoring. Dafür stehen ein globaler Resource Manager (RM) und ein

applikationsspezifischer Application Master (AM) zur Verfügung, wobei eine Applikation ein herkömmlicher MapReduce-Job oder eine komplexe Zusammenstellung sein kann. Mit Yarn soll der Einsatzbereich von Hadoop erweitert und die Geschwindigkeit der Hadoop-

Operationen erhöht werden.

ZooKeeper: Apache ZooKeeper erledigt das zentralisierte Konfigurationsmanagement von Hadoop-Umgebungen. Es verwaltet die Konfiguration, das Naming oder auch

Synchronisierungsprozesse innerhalb verteilter Systeme.

(32)

TU Darmstadt

informatik.tu-darmstadt.de. Abgerufen am 15. 07 2013 von http://www.informatik.tu- darmstadt.de/BS/Lehre/Sem98_99/T11/

Verifikation digitaler Signaturen

2 Kryptographische Grundlagen

In der Kryptographie unterscheidet man zwei verschiedene Arten der Verschlüsselung: die symmetrische und die asymmetrische Verschlüsselung.

Bei der symmetrischen Verschlüsselung benutzen Sender und Empfänger einer Nachricht den gleichen Schlüssel zum Verschlüsseln und Entschlüsseln. Problematisch sind symmetrische Verfahren im Zusammenhang mit digitalen Signaturen aus verschiedenen Gründen. Die wichtigsten sind:

• Die Zahl der Schlüssel ist sehr groß, da jeweils zwei Teilnehmer einen gemeinsamen Schlüssel vereinbaren. Bei n Teilnehmern sind das [(n(n-1))/ 2] Schlüssel.

• Der Austausch von Schlüsseln kann nicht auf dem gleichen Medium geschehen.

• Da beide Teilnehmer den gleichen Schlüssel besitzen, könnte im Streitfall nicht nachgewiesen werden, wer von beiden mit dem Schlüssel die Unterschrift geleistet hat.

Mit asymmetrischen Verfahren kann man die oben beschriebenen Probleme lösen. Deshalb werden sie bei digitalen Signaturen eingesetzt.

2.1 Asymmetrische Verschlüsselung

Die Idee der asymmetrische Verschlüsselung wurde erstmals im Jahr 1976 von Diffie und Hellman in ihrem Aufsatz "New Directions in Cryptography" [DH76] veröffentlicht. Darin führen die Autoren das Prinzip asymmetrischer Kryptographie ein. Doch erst 1978 stellten Rivest, Shamir und Adleman mit RSA das erste asymmetrische Verschlüsselungsverfahren vor [RSA78]. Das nach seinen Autoren genannte Verfahren ist inzwischen zum de-facto Standard geworden.

Asymmetrische Verschlüsselung funktioniert in folgender Weise: Jeder Teilnehmer erzeugt sich ein Schlüsselpaar bestehend aus einem öffentlichen Schlüssel e und einem geheimen Schlüssel d. Das System ist so konzipiert, daß der private Schlüssel aus dem öffentlichen Schlüssel nur in nicht vertretbarer Zeit zu berechnen ist¹.

Wenn Alice eine Nachricht m an Bob schicken möchte, benötigt sie Bobs öffentlichen

Schlüssel e_Bob. Diesen bekommt sie entweder von Bob persönlich oder aus einem öffentlichen Schlüssel-Verzeichnis.

Alice benutzt die Verschlüsselungsfunktion E und berechnet die verschlüsselte Nachricht c mit

c = EeBob (m)