Oracle Security Reporting Tool – DBSAT

Veröffentlicht am 19. April 2018 von

Hallo Community,

aus gegebenen Anlass möchte ich ein paar Worte über Oracle DBSAT – Database Security Assessment Tool verlieren. Ein kleines, kostenloses aber sehr mächtiges Security Reporting Tool für Oracle Datenbanken.

Wir hatten die Möglichkeit das Tool auf der Inspire IT in Frankfurt einigen Kunden vorzustellen.
Sowohl die Verprobung des Tools an sich wie auch die Veranstaltung hat uns sehr viel Spaß bereitet.

Grundsätzlich ist das nichts Neues – Security und Datenschutz sind wichtig und auch teuer, sollten dennoch immer im Unternehmen gelebt werden. Spätestens dann, wenn Firmendaten im Internet für jeden ungewollt einsehbar sind, wurde etwas gänzlich falsch gemacht und nicht selten wird das Unternehmen einen riesigen Imageschaden über Jahre hinweg davontragen.

–> Security und Datenschutz nicht ernst zu nehmen, kann demnach sehr, sehr nachhaltig und gnadenlos sein. Daher lieber vorsorgen. 🙂

Im Zuge der neuen EU-weiten Datenschutzverordnungen (GDPR und DSGVO) zum Stichtag 25.5.2018 sollten Datenbanken entsprechend vielleicht doch noch mal überprüft und sicherer gemacht werden.

Und genau da kommt DBSAT ins Spiel: Es gibt immer wieder kleine hilfreiche, kostenlose Tools, die das Leben eines DBA für Oracle Datenbanken einfacher machen und dies gehört wie auch schon OraChk definitiv in diese Liste.

Als langjähriger Admin weiß ich, dass einem Schema oftmals „sysdba“ Rechte herausgegeben werden, „um mal eben kurz etwas in der DB mit Admin Rechten zu machen“, was leider aber auch genauso häufig und schnell wieder vergessen wird. Das darf nicht sein!

 

Regelmäßiges Reporting zeigt unter anderem solche Schwachstellen und kann alarmierend und vorsorglich helfen.

Ein kleiner DBSAT Daemon, der zum Beispiel wöchentlich oder täglich gescheduled und regelmäßige Security Reports in unterschiedliche Formate HTML, JSON, XLS zieht, wirkt wahre Wunder.

Obendrauf gibt es noch für den DBA über das HTML Format noch diverse „Best Practice“ Anweisungen für eine sichere Datenbank.

DBSAT unterscheidet sich im Prinzip in drei Kategorieren:

Collector

– führt die SQL- und OS-Kommandos aus
– schreibt die gesammelten Daten in eine Json-Datei

Reporter

– analysiert die gesammelten Daten
– generiert einen DBSAT-Report in HTML, Excel und Text-Format und packt diese in ein verschlüsseltes Zip-File

Discoverer

– durchsucht das Datemodell nach Datenschutz- und Sicherheits-relevanten Spalten
– führt SQL-Abfragen aus und sammelt Daten basierend auf Config-Files
– generiert einen „Sensitive Data“ Report im HTML- und CSV-Format Format und packt diese in ein verschlüsseltes Zip-File.

Je nach Anwendungsfall bleiben dem Anwender mehrere Einsatzmöglichkeiten, wenn der Security-Bericht noch genauer und spezieller erzeugt werden soll.

Anwendungsbeispiel:

dbsat1

Daten sammeln:

dbsat3

Erstellung des Reports:

dbsat2

dbsat_neu

HTML Ergebnis des Security Berichtes:

dbsat_erg1

 

dbsat_erg2

Was überprüft DBSAT?

Auf der Agenda stehen natürlich die einhergehenden Benutzerkonten, Berechtigungen und Rollen plus deren Berechtigungsteuerung, wie auch Datenverschlüsselung, Zugriffssteuerung und Audit-Richtlinien. Datenbank, Listenener-Konfiguration, Dateiberechtigungen und sensitive Daten werden ebenso überprüft.

Durch einfache Installation, also Herunterladen, Entpacken und Ausführen des Kommandozeilen Tools kann kurzerhand ein Security Report ohne große Vorkenntnisse erstellt werden. Es ist anzuraten, diese Reports „secure“ und gesondert auf einem Server bzw. in einer DB aufzubewahren, da es sich um sicherheitsrelevante Daten handelt.

Da eine Ausgabe im JSON-Format super weiterverarbeitet werden kann, leite ich dieses in Kibana/Splunk oder gar Spark Graphx weiter, um angepasste Graphen zu basteln. Muss man nicht, aber alleine die Option, andere Tools über JSON mit anzubinden, finde ich sehr löblich.

DBSAT kann ab 10g bis 18c Oracle DB’s eingesetzt werden, dabei kann es sich um ein 64-Bit Linux, Solaris, AIX, HPUX oder Windows handeln. Benötigt werden Python ab 2.6 (Collector+Reporter) bzw. Java ab 1.6 (Discoverer).

Ein kurzer Screenshot zeigt die Vorgehensweise unter Linux. Dies kann sowohl als System Benutzer ausgeführt werden als auch als expliziter DBSAT Benutzer innerhalb der Oracle Datenbank. Dann müssen aber minimale Rechte je nach Version an das DBSAT Schema gegeben werden.

CREATE SESSION *
SELECT on SYS.REGISTRY$HISTORY
Role SELECT_CATALOG_ROLE *
Role DV_SECANALYST * (if Database Vault is enabled)
Role AUDIT_VIEWER (12c and later)
Role CAPTURE_ADMIN (12c and later)
SELECT on SYS.DBA_USERS_WITH_DEFPWD (11g and later)
SELECT on AUDSYS.AUD$UNIFIED (12c and later)
(*: ausreichend für den Discoverer)

Zusammengefasst hat DBSAT den Nutzen:

– Sensible Daten in der Datenbank zu finden und vor Dritten zu schützen, wenn resultierende Maßnahmen durch DBA ergriffen werden

– Identifizieren von Risiken durch Fehlkonfigurationen

– Datenbankbenutzer und deren Berechtigungen hinterfragen

– Empfehlungen von Sicherheitsmaßnahmen zur Unterstützung von Compliance-Anforderungen

 

Apropos: nochmals vielen Dank an Oracle, dass die Deutsche Sprachdatei „sensitive_de.ini“ für den Discoverer, welche aktuell noch nicht in Version 2.0.1 enthalten war, uns bei OPITZ CONSULTING noch rechtzeitig vor der Konferenz erreichte.

DBSAT ist natürlich wie sein Vorgänger für Oracle-Kunden kostenfrei. Jeder Kunde mit einem aktiven Supportvertrag kann dieses Werkzeug unter Oracle Support Document 2138254.1 beziehen.

 

Noch ein paar abschließende Links:

 

Hier noch mal der Hinweis:

EU-Datenschutz-Grundverordnung (EU-DSGVO) verabschiedet!

Die EU-Datenschutz-Grundverordnung (EU-DSGVO) ist am 14. April 2016 durch das EU-Parlament beschlossen worden. Sie ist am 04.05.2016 im Amtsblatt der Europäischen Union veröffentlicht worden und tritt damit am 25.05.2016 in Kraft. Anwendbar ist sie damit ab dem 25. Mai 2018.

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , , | Kommentar hinterlassen

AWS kann Big Data Analytics – aber wie?!

Veröffentlicht am 16. April 2018 von

Als Partnerunternehmen von Amazon wird von uns bei OPITZ CONSULTING eigentlich immer erwartet, dass wir die durch AWS zur Verfügung gestellte Plattform bestens kennen. Unsere Kunden tun das – und Amazon selbst eigentlich auch. Damit wir dieser Erwartungshaltung gerecht werden, müssen wir permanent am „Puls der Zeit“ sein und die aktuellen Entwicklungen in den jeweiligen Technologien und Produkten verfolgen und verstehen. Dann und wann muss bzw. darf der geneigte Berater dann allerdings auch sein permanentes Selbststudium eintauschen gegen einen durch den Hersteller veranstalteten Workshop.

Genau so ein Workshop bzw. eine Workshopreihe ist die brandneue AWS Data Master Path Series, eine Folge von drei eintägigen Workshops, bei dem die Teilnehmer durch sachkundige Lösungsarchitekten durch verschiedene Aspekte der AWS-Landschaft geführt werden. Konkret geht es in den drei Terminen um

  • Big Data und Data Lake,
  • Internet of Things (IoT) und
  • Machine Learning (ML)

und wie diese Lösungen mittels in AWS vorhandener Komponenten aufgebaut werden können. Selbstredend ist das nur die AWS-Sicht der Dinge, aber genau die ist ja wichtig um zu verstehen, wie welche Komponenten gemäß ihrem Hersteller miteinander kombiniert und zu einem effektiven Lösungsdesign verwoben werden können.

Am 12. April hat nun der europaweit erste Termin in Berlin stattgefunden. Teilnehmer waren insgesamt 17 Berater unterschiedlicher Partner von AWS, darunter auch drei meiner Kollegen und ich selbst. Zum Auftakt gab es quasi einmal den theoretischen „Rundumschlag“ zu AWS: Was kann es alles, welche Produkte stecken drin und sind für welche Aufgaben zuständig? Trotz meiner Befürchtung, dass dieser „Workshop“ zu stark in die Theorie abdriftet, wurde dem Vortragsmonolog bald ein Ende gesetzt und es begann die Zeit der Hands-on-Übungen, welche den Kern des gesamten Workshops bildeten:

  1. Zuerst ging es um Kinesis mit seinen Komponenten Kinesis Streams, Kinesis Firehose und Kinesis Analytics (immer flankiert vom unweigerlichen S3 als der Basis eines Data Lake nach AWS-Manier). Es wurde innerhalb kürzester Zeit ein Eventstream erzeugt, der in S3 persistiert wurde. Dabei wurden mittels Kinesis Analytics per SQL-artiger Befehle Kennzahlen auf dem Datenstrom erzeugt wie bspw. Aggregationen über eine bestimmte Gruppe von Events oder ein bestimmtes Zeitfenster.Kinesis
  2. Nach dem Mittagessen, welches ganz in typischer IT-Manier gehalten war, ging es dann um den theoretischen Lösungsentwurf für einen gegebenen Anwendungsfall. In Gruppen wurden so Grobarchitekturen erarbeitet, die – wie wir später erfuhren – auf konkreten und bereits auf AWS umgesetzten Lösungen basierten. So konnten wir also bereits unser erworbenes Wissen auf seine Konsistenz und Vollständigkeit hin überprüfen.Architektur
  3. Anschließend wurde es wieder etwas handfester mit einer Übung zu den Themen Glue, Athena und Quicksight. Die in Übung 1 erzeugten Daten wurden nun also transformiert, analysiert und mittels QuickSight visualisiert. Hierbei wurde schnell deutlich, wie wichtig eine saubere Optimierung von Datenstrukturen und -abfragen ist, denn im Falle von Athena erfolgt die Abrechnung bspw. anhand der für die Beantwortung einer Abfrage gescannten Datenmenge. Vergisst man hier einen Filter oder eine Partitionierung, kann das schnell ein teures Vergnügen werden.
  4. Zum Schluss des Workshops gab es dann noch eine Übung zum Thema AWS Elastic MapReduce (EMR) in Kombination mit Hive und Spark SQL sowie Zeppelin. Hier besticht die Kürze der Zeit, innerhalb derer man einen vollständigen Rechencluster zur Verarbeitung seiner (in S3 befindlichen) Daten hochziehen und damit anfassbare Ergebnisse produzieren kann.

 

Hieran anschließend hätte es noch eine fünfte Übung zum Produkt Redshift gegeben, doch war leider – leider! –  zu diesem Zeitpunkt der Tag schon wieder rum, so dass wir diese Übung nur als „Hausaufgabe“ mit nach Hause nehmen konnten.Pizza

 

Als Fazit bleibt, dass es Amazon gelungen ist, innerhalb eines Tages einen (kleinen) Überblick über seine Produktpalette und damit lösbare Anwendungsfälle zu geben. Selbstredend ist das nur die Spitze des Eisbergs, und sicherlich kann dieser Workshop nicht die tiefere Beschäftigung mit den Produkten und Technologien ersetzen, aber als kompakter Einstieg in die Welt von AWS, und wie Amazon selbst sie sieht, war es eine gelungene Veranstaltung mit netten und kompetenten Trainern. Ich freue mich bereits auf die folgenden Termine.

Veröffentlicht unter Analytics & BigData, Cloud & Infrastructure, Uncategorized | Kommentar hinterlassen

Eindrücke vom AWS Dev Day in Köln

Veröffentlicht am 16. April 2018 von

Am 12.04.2018 fand in Köln der AWS Dev Day statt. Ich hatte das Glück bei dem ausgebuchten, kostenfreien Event dabei sein zu dürfen.

Der AWS Dev Day fand in der beeindruckenden Eventlocation Pattenhalle in Ehrenfeld statt. Gleich nach der Registrierung gab es einen kleinen Frühstücks-Snack. Das lässt man sich natürlich nicht entgehen. Ein zweites Frühstück hat noch keinem geschadet… 😉

20180412_083926

Frisch gestärkt hatte ich die Wahl mich zwischen vier parallelen Tracks zu entscheiden: Artificial Intelligence, Database Analytics, Serverless und Containers. Ich entschied mich für „Serverless: State of the Union“.

Agenda

Der Track gab einen guten Überblick über die aktuellen Entwicklungen im Bereich „Serverless“. Interessant fand ich das AWS Serverless Application Repository. Darin findet man bereits eine Menge an Beispielapplikation für typische Anwendungsfälle. Das erleichert den Einstieg in dieses Thema enorm, wenn man sich an bereits lauffähigen Anwendungen orientieren kann. Weiterhin interessant war der Support von XRay in Lambda, womit ein Tracing der Aufruf-Requests komfortabel ermöglicht wird, sowie Serverless Aurora, bei der das Serverless-Paradigma auch auf Datenbankebene Einzug hält.

Weiter ging es in dem Track „Containers“ mit dem Vortrag zu „Deep Dive on Amazon Elastic Container Service (ECS)“. Entgegen dem Titel ging es nicht so weit in die Tiefe; der Vortrag gab aber einen guten Einstieg in das Thema Containermanagement auf der AWS Plattform. Interessant fand ich den Amazon ECR Credential Helper, der das Token-Handling der Authentifizierung ohne docker login am ECR Repository automatisiert.

Als nächsten Track besuchte ich „Amazon Elastic Container Service for Kubernetes (Amzon EKS)“. Mit Amazon EKS wird der Aufbau eines gemanagten, hochverfügbaren Kubernetes-Cluster extrem vereinfacht. Dabei erkennt Amazon EKS automatisch degenerierte Master-Knoten und stellt Versions-Upgrades und Patches für die Master bereit.

In der Mittagspause wurden die Teilnehmer mit leckerem Chili Con Carne versorgt. Dabei kam auch die Möglichkeit sich mit anderen Gleichgesinnten auszutauschen nicht zu kurz, bevor ich mich dann weiter in den nächsten Containers-Track stürzte.

Diesmal ging es um „Deep Dive on Fargate“. In dem Track wurde noch mal ausführlicher erläutert, um was es sich bei AWS Fargate eigentlich handelt. AWS Fargate ist eine Buchungsoption innerhalb von AWS ECS, bei der man sich nicht selbst um die Verwaltung der genutzten EC2-Instanzen und Cluster kümmern muss. Diese Option soll es sowohl bei ECS, als auch bei EKS zukünftig geben. Der Entwickler kann sich damit noch mehr auf die eigentliche Entwicklung der Anwendung innerhalb des Containers konzentrieren, ohne sich um die Verwaltung der Server (z.B. Patching der Amazon Machine Images (AMI) etc.) selbst kümmern zu müssen.

Der letzte Vortragsslot war ein Sponsored-Talk mit dem Titel „Future Mobility Platform on AWS: Global Rollout with Gitlab and Kubernetes“. Dieser Vortrag war ein Erfahrungsbericht aus einem Real-Life-Projekt auf der AWS-Plattform. Hier ging es um das IoT-Thema „Connected Car“ mit Hilfe von Kubernetes auf AWS mit mehreren Regions und verteilen Teams.

Fazit

Der Tag war eine schöne „Aus-Zeit“ vom Alltag, um sich noch mal über die neuesten Entwicklungen auf der AWS-Plattform informieren zu können. In den vier parallen Tracks konnte sich jeder die für ihn interessantesten Themen heraussuchen. Die Vorträge von AWS selbst, wie von den Sponsored-Talks waren durchgängig mit Live-Demos ergänzt, so dass die Zuhörer gleich den praktischen Einsatz direkt miterleben durften. In den Pausen und nach der Veranstaltung blieb genug Zeit mit den AWS-Mitarbeitern in Kontakt zu treten, sowie sich mit anderen Teilnehmern auszutauschen. Die hervorragende kulinarische Versorgung, sowie das frühlingshafte Wetter machte das Event zudem zu einem echten Erlebnis.

Veröffentlicht unter Cloud & Infrastructure | Kommentar hinterlassen

Managed Services – eine Alternative zur Arbeitnehmerüberlassung

Veröffentlicht am 9. April 2018 von

Was ist ANÜ überhaupt?

Alle reden von ANÜ. Nur warum? Und was ist das überhaupt?

Grundsätzlich liegt eine ANÜ (Arbeitnehmerüberlassung) dann vor, wenn Arbeitnehmer (Leiharbeitnehmer) von einem Arbeitgeber (Verleiher) einem Dritten (Entleiher) gegen Entgelt für begrenzte Zeit überlassen werden. Rechte und Pflichten eines Arbeitgebers übernimmt der Verleiher und der Leiharbeitnehmer steht weiterhin in einem Arbeitsverhältnis zum Verleiher. Den rechtlichen Rahmen hierfür bildet das „Gesetz zur Regelung der Arbeitnehmerüberlassung“ (AÜG).

Mit der Reformierung, die zum 01.04.2017 in Kraft getreten ist, sind auch einige Änderungen aktiv, die Auswirkungen auf verschiedene Auftragsformen in der IT haben.

Mit der Reformierung vom 01.04.2018 traten Änderungen in Kraft, die Auswirkungen mit erheblichen Nachteilen auf die Auftragsformen in der IT haben.

Arbeitnehmerübernahme

Darstellung: Was ist Arbeitnehmerübernahme?

Nachteile von ANÜ

Welche Nachteile sind das?

Ein Mitarbeiter, der per ANÜ bei einem Kunden im Einsatz ist, muss nach spätestens 18 Monaten den Kunden wechseln. Mit jedem Wechsel geht dem Kunden Projekt-Know-how verloren, das Mitarbeiter in der IT-Branche im Projektkontext aufbauen. Daraus resultiert, dass mit jedem neuen Mitarbeiter eine erneute Einarbeitung erforderlich wird. Dies belastet jedes Projekt und wirkt sich auch auf den Projekterfolg aus.

Ein weiterer Nachteil ist, dass über ANÜ nicht so einfach skaliert werden kann, wenn der Bedarf besteht, weil für jeden Mitarbeiter die ANÜ vertraglich transparent geregelt werden muss. Jeder neue Vertrag benötigt Zeit für die Abstimmung mit den Mitarbeitern (Wer ist der Richtige? Passt er ins Team? Wie lange werde ich ihn brauchen? Will er per ANÜ arbeiten? …)

Ein weiteres Problem ist die Themenvielfältigkeit in den Projekten. Ich bin mit den Projektaufgaben an das Know-how der Mitarbeiter gebunden, die ich per ANÜ entliehen habe. Was passiert, wenn temporär neue oder andere Aufgaben entstehen und damit andere Skills benötigt werden? Mit dem aktuellen Mitarbeiter bin ich zufrieden, kann ihn in den nächsten Wochen nur nicht auslasten, da seine Skills nicht passen. Ich benötige diesen Mitarbeiter jedoch später wieder für den Projekterfolg.

Managed Services als Antwort

Unsere Antwort auf die Nachteile, die sich mit der ANÜ ergeben sind – Managed Services. Trotz des temporären Einsatzes unserer Experten im Unternehmen eines Kunden, grenzen sich OC|Managed Services deutlich von Arbeitnehmerüberlassungen (ANÜ) – oder auch von Leiharbeit – ab. Managed Services bergen somit kein Risiko, in die Falle einer unerlaubten Arbeitnehmerüberlassung zu tappen, die häufig im IT-Projektgeschäft vorgefunden wird.

Zunächst sind die Mitarbeiter von OPITZ CONSULTING in der Regel nicht immer vor Ort bei den Kunden, arbeiten mit ihren eigenen Arbeitsmitteln, die sie nicht vom Auftraggeber gestellt bekommen, sondern nutzen eigene Hardware. Über Remote Zugänge und Offsite-Arbeitsplätze lassen sich die Aufgaben in Eigenregie bearbeiten.

Unsere Mitarbeiter sind zudem nicht in die Arbeitsabläufe und Prozesse der Kunden eingegliedert.

Die beiden letztgenannten Punkte führen oft dazu, dass eine Leistung als ANÜ gewertet wird

Die Erfüllung der vertraglichen Verpflichtungen, die häufig in SLAs gemessen werden, erfolgen selbstorganisiert durch die Mitarbeiter und nicht auf Weisung des Auftraggebers.

Die Vertragspflicht im Rahmen eines Managed Services endet im Vergleich zur Arbeitnehmerüberlassung nicht mit der Auswahl und Zurverfügungstellung eines Arbeitnehmers und nach 18 Monaten, sondern wir schulden die Erfüllung eines Services.

Die eingesetzten Arbeitnehmer sind als Erfüllungsgehilfen zu betrachten und unterliegen weiterhin den Weisungen von OPITZ CONSULTING. Der sogenannte Dritte in diesem Verhältnis, also unser Kunde, kann jedoch entsprechend § 645 Abs. 1 Satz 1 BGB dem Unternehmer oder seinen Erfüllungsgehilfen sogenannte werk-/objektbezogene Anweisungen für die Werkserstellung erteilen. Gleiches gilt bei Dienstverträgen.

Ein weiterer Vorteil liegt in der flexiblen Skalierung: Bei unseren Services werden keine dedizierten Mitarbeiter verliehen, sondern ganze Teams. Je nach Thema und Dringlichkeit können also weitere Mitarbeiter hinzugezogen werden. Dies sichert eine qualitativ hochwerte Erfüllung. Getreu dem Motto: „Die Richtige für das richtige Problem.“ sorgen wir für das entsprechende Know-how und dessen Verfügbarkeit.

Managed Services stellen also tatsächlich Services dar, die wir dem Kunden anbieten und kein Verleihen von Mitarbeitern.

 

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Bewertung des CI/CD Tool Jenkins

Veröffentlicht am 9. April 2018 von

Teil 2 der Serie

Nach der Definition eines Kriterienkatalogs im ersten Teil der Serie (https://thecattlecrew.net/2017/11/28/kriterien-fuer-die-bewertung-von-ci-cd-tools/) beginnt nun die Bewertung der CI/CD Tools. Ich fange mit Jenkins an, welches als das Tool mit der größten Verbreitung unter den CI/CD Tools gilt. Bekannt ist es vor allem durch die populäre Erweiterbarkeit mit Plugins. Bei Jenkins handelt es um ein in Java geschriebenes Tool, dass unter der MIT-Lizenz verfügbar ist. Darauf folgen unter anderem Bewertungen der CI/CD Tools GitLab CI und Concourse CI.

Skalierung

Jenkins ermöglicht durch die Unterstützung von Remote-Agents die Skalierung der Ausführung auf mehreren Maschinen. Die Maschinen werden als Slaves bezeichnet. Mit den Slaves wurde die Distributed Architecture eingeführt, die es ermöglicht, mehrere Slaves anzulegen und diese mit dem Master zu verbinden. Dadurch kann die Ausführung von Jobs auf die Slaves verteilt werden, um die Abarbeitung von Jobs zu beschleunigen. Es gibt verschiedene Varianten diese zu starten. Dazu zählen via SSH, on Windows, own Script, via Java Web Start und headlessly. Die Slaves können on-premises betrieben oder über eine SaaS-Lösung wie Cloudbees in Anspruch genommen werden.

Weitere Details sind unter den folgenden Links zu finden:

https://wiki.jenkins.io/display/JENKINS/Distributed+builds#Distributedbuilds-Differentwaysofstartingagents

https://www.cloudbees.com/blog/scaling-jenkins-slaves

 

Build-Möglichkeiten

Jenkins bietet mit Distributed Builds, Parallel Builds und Triggered Builds eine Vielzahl an Build-Möglichkeiten. Bei Distributed Builds handelt es sich um die Verteilung von Build Jobs auf mehreren Servern. Ein Knoten beinhaltet dabei eine alleinstehende Installation des Masters vom Jenkins, der alle Aufgaben für das Build System steuert. Meistens werden dazu, wie im vorherigen Abschnitt erwähnt, auf anderen Systemen sogenannte Slaves aufgesetzt, auf die man die Aufgaben verteilen kann. So wird vermieden, an die Grenzen der Maschine zu kommen, auf der der Master installiert ist. Damit übernimmt der Master lediglich die Steuerung und baut die Builds nicht selbst. Das Bauen der Builds übernehmen die Slaves. Aber auch Parallel Builds, bei denen parallele Stages ausgeführt werden können, werden durch die Jenkins Pipeline ermöglicht. Ein gutes Beispiel hierfür wäre das Parallelisieren von Tests, um JUnit-Tests parallel mit Integrationstests durchzuführen. Zu guter Letzt gibt es natürlich auch noch die Möglichkeit, Builds über Trigger anzustoßen. Es kann zum Beispiel eingestellt werden, dass ein Build in Abhängigkeit von dem Ergebnis eines anderen Builds ausgeführt werden soll.

Weitere Details sind unter den folgenden Links zu finden:

https://wiki.jenkins.io/display/JENKINS/Distributed+builds

https://wiki.jenkins.io/display/JENKINS/Pipeline+Plugin

 

Rechteverwaltung von Benutzern und Gruppen

Jenkins bietet per Default keine Unterstützung für die Rechteverwaltung auf Rollen- oder Projektebene an. Doch wie Sie vielleicht bereits erahnen können, gibt es auch hierfür ein Role Strategy Plugin, mit dem man globale Rollen wie Admin oder Job Creater definieren kann. Aber auch die Erstellung von Projektrollen, die nur auf Projektbasis Jobs anlegen und ausführen können, ist mit dem Plugin möglich. Es ist zu empfehlen, diese Form der Rechteverwaltung nur zu nutzen, wenn es der Use Case wirklich erfordert, da diese sehr flach und einfach gehalten ist.

Weitere Details sind unter den folgenden Links zu finden:

https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin

 

Container Management

Es gibt in Jenkins keine native Container Unterstützung. Konkret gibt es für die Container Engine aber Support durch ein entsprechendes Plugin. Dazu muss das Docker Plugin installiert werden, um dann mit Jenkins einen Docker Host zu kontrollieren, der wiederum Builds in Form von Containern anstoßen kann. Eine Möglichkeit wäre die Nutzung einer externen Registry, wie z.B. der Service EC2 Container Registry von Amazon, in Jenkins zu integrieren.

Aus eigener Erfahrung weiß ich, dass ein erfolgreicher Build über Jenkins nicht unbedingt bedeutet, dass der Docker Container fehlerfrei läuft. Um sicherzugehen, dass der Jenkins-Container wirklich fehlerfrei läuft, wären zusätzliche Überprüfungen notwendig.

Weitere Details sind unter den folgenden Links zu finden:

https://wiki.jenkins.io/display/JENKINS/Docker+Plugin

https://cloud.google.com/container-registry/?hl=de

 

Notifications und Monitoring

Das Notification-Plugin erlaubt es, Job Status Notifications im JSON und XML Format zu versenden. Dabei können das Format (JSON/XML), das Protokoll (HTTP, TCP, UDP), das Event (Job started, Job completed, all events), die URL, an die versendet werden soll, und ein Timeout angegeben werden. Diese werden dann per E-Mail zugestellt, wozu natürlich vorher ein SMTP-Server konfiguriert werden muss.

Neben der E-Mail sind noch weitere Wege möglich, um über Ereignisse zu informieren. Dazu gehören zum Beispiel Notifications über Slack, Rocket.Chat, Telegram und vieles mehr. Da Jenkins Open-Source ist, sind viele Kanäle bereits durch Plugins abgedeckt oder werden in Zukunft noch abgedeckt.

Wie für die Notifications existiert auch für das Monitoring ein Plugin, bei dem per Default JavaMelody verwendet wird. Java Melody ist ein Monitoring-Framework für Java oder JavaEE Applikationen, mit dem sehr viele Details grafisch in Form von Charts angezeigt werden können. Neben JavaMelody gibt es auch noch andere Möglichkeiten.

Weitere Details sind unter den folgenden Links zu finden:

https://wiki.jenkins.io/display/JENKINS/Notification+Plugin

https://wiki.jenkins.io/display/JENKINS/Monitoring

 

Anderweitige Evaluierung

Durch die hohe Anzahl an Plugins ist die Flexibilität des Tools sehr hoch und damit auch sein Funktionsumfang. Jedoch ist hier Vorsicht geboten, weil viele Plugins unter Umständen nicht aktuell sind und damit sicherheitstechnische Lücken beinhalten können. Zudem machen es Plugins dem Anwender schwer, zu erkennen, ob ihr Einsatz für ein bestimmtes Szenario sinnvoll ist oder nicht.

Ein Blick in den Issue Tracker vom Jenkins, der einmal für den Jenkins selbst existiert aber auch für jedes einzelne Plugin kann dabei helfen, zu erkennen, ob ein Plugin sehr veraltet ist oder ob es regelmäßig aktualisiert wird.

Wichtig dabei ist eine gute Dokumentation, die von Jenkins leider nicht an allen Stellen gegeben ist. Zum Jenkinsfile zum Beispiel fehlen in der offiziellen Dokumentation  Befehlsreferenzen. Wenn man sich auf die Suche nach diesen macht, landet man also schnell im Source Code.

Nichts desto trotz ist Jenkins sehr weit verbreitet.  Die zahlreichen Erweiterungen in Form von Plugins und auch der Open-Source-Faktor spielen dabei eine sehr große Rolle. Dazu steht eine starke und hilfsbereite Community hinter Jenkins, weswegen ein gewisser Coolness Faktor gegeben ist. Bei Problemen kann man sich über GitHub an die Community wenden und erhält bereits nach kurzer Zeit Antworten.

 

Continuous Delivery

Die Einführung der Jenkins Pipeline DSL ermöglicht es den Benutzern, Pipeline as Code zu verwenden. Dabei werden mehrere Stages in einem Jenkinsfile definiert, dass wiederum als Code neben dem eigentlichen Code gesehen wird. In dem Jenkinsfile können dann Stages wie Build, Test oder Upload definiert werden, die alle erfolgreich verlaufen müssen, damit die Pipeline als erfolgreich angesehen wird. Dadurch ist eine hohe Flexibilität gegeben und die Unterstützung für Continuous Delivery gewährleistet.

Weitere Details sind unter den folgenden Links zu finden:

https://github.com/openshift/jenkins

https://wiki.jenkins.io/display/JENKINS/Cloud+Foundry+Plugin

https://jenkins.io/solutions/pipeline/

 

Kosten

Zu guter Letzt kommen wir zu den Kosten. Dabei wurde als Faktor ein Entwicklerteam von 30 Entwicklern ausgewählt. Da es sich bei Jenkins um ein Open-Source-Tool handelt, entstehen on-premises keinerlei Kosten bei der Nutzung des Tools. Dies gilt auch für die Remote Agents, die man on-premises ausführt.

Um einen Vergleich zu erhalten, wurde der Software as a Service Anbieter CloudBees ausgewählt, der eine Lösung für Jenkins bereitstellt. Leider müssen in dem Fall die Preise individuell angefragt werden, da mehr Faktoren als die Größe des Teams in den Preis einfließen.

 

Fazit

Jenkins bietet als Open-Source-Tool sowohl für den Continuous Integration als auch für den Continuous Delivery Bereich eine Vielzahl an Unterstützungsmöglichkeiten. Dies wird vor allem durch die hohe Anzahl an Plugins gewährleistet. Diese hohe Flexibilität spricht für das Tool und macht Jenkins auch in Zukunft zu einem einsetzbaren Kandidaten für Projekte. Das Plugin-Ökosystem ist aber auch zugleich die Kehrseite der Medaille. Es spricht sehr stark gegen das Prinzip des Single Source of Truth und erschwert die Update Strategie, weil die Kompatibilität zwischen den Plugins und Jenkins sichergestellt werden muss. Dazu kommt der initial sehr verwirrende administrative Aufwand, der zu einem hohen Einarbeitungsaufwand führt. Nichts desto trotz ist Jenkins ein mächtiges Tool, das dem Entwickler immer noch sehr viele Möglichkeiten bietet..

Veröffentlicht unter Software Engineering | Kommentar hinterlassen

Dynamische Genehmigung

Veröffentlicht am 6. April 2018 von

Wie modelliere ich eine Situation, in der Entscheidungen durch verschiedene Personen geprüft werden sollen?

Das Thema Vier-Augen-Prinzip kennen sicher viele, die sich hin und wieder mit Prozessmodellierung beschäftigen: Als Bank möchte ich beispielsweise sicherstellen, dass die Kreditentscheidung eines Mitarbeiters von einer Kollegin geprüft und diese Prüfung dokumentiert wird. Ähnliche Anforderungen begegnen uns, wenn in einer Versicherung eine Risikoentscheidung getroffen werden soll.

vier_augen_prinzip

Genemigung mit zwei Genehmigern

Ein einfacher Weg, diese Situation zu modellieren, ist die Nutzung eines Human Task für jeden Genehmigungsschritt: Die Process-Engine erstellt einen Human Task und weist den Fall einem Genehmiger zu. Dieser prüft den Fall und dokumentiert seine Entscheidung. Ist die Anfrage genehmigt, wird der Fall über einen Human Task einem weiteren Genehmiger vorgelegt, anderenfalls endet der Prozess. Der zweite Genehmiger prüft nun den Fall und dokumentiert seine Entscheidung. Hat auch er genehmigt, gilt die Anfrage als genehmigt, sonst ist der Fall abgelehnt.

Doch was tun, wenn fallweise weitere Genehmiger hinzukommen sollen, beispielsweise weil ab einer gewissen Auftragshöhe der Fall einem Abteilungsleiter oder einer Geschäftsführerin vorgelegt werden soll? Wir könnten unser Modell um weitere Human Tasks und Gateways, die die Entscheidung abbilden, erweitern. je nach Komplexität kann das aber sehr schnell sehr unübersichtlich werden. Einfacher ist es, diese Dynamik bereits im Prozessmodell zu berücksichtigen.

dynamische_genehmigung

Dynamische Genehmigung mit Rule-Task und Mehrfach-Instanzen

In unserem Beispiel wird anhand eines Regelwerks für den vorliegenden Fall eine Liste von Genehmigern ermittelt. Damit verstecken wir die Details der Entscheidung vor dem Betrachter unseres Prozessmodells. Die Modelierung und Auswertung der Regeln erfolgt gesondert, zum Beispiel mithilfe der DMN.
Für jeden Eintrag der so ermittelten Liste wird sequentiell ein Human Task erzeugt und einem Genehmiger zugewiesen. Sobald ein Genehmiger die Anfrage ablehnt, gilt der Fall insgesamt als abgelehnt, es werden somit keine weiteren Human Tasks mehr erzeugt.

Das Beispiel kann noch flexibler gestaltet werden, indem die Genehmiger parallel anstatt sequentiell benachrichtigt werden. Die BPMN bietet zudem die Möglichkeit, eine Bedingung für die Beendigung einer Mehrfach-Ausführung zu formulieren. Damit könnten wir beschreiben, dass der Fall per Mehrheitsbeschluss genehmigt ist, sobald zwei von drei Genehmigungen vorliegen. Alternativ könnten wir ein Regel-Set definieren, um nach Erhalt aller Rückmeldungen über die Fallgenehmigung zu entscheiden, beispielsweise um einzelnen Stimmen mehr Gewicht zu verleihen.

Dieses und weitere Prozessmuster finden Sie auch auf unserem Poster ‚Erfolgreiche BPM-Pattern aus der Praxis‘

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Holiday replacement using camunda candidate groups

Veröffentlicht am 6. April 2018 von

In a recent project I was faced by a real classic in user task management. The age old question about how to handle holiday replacement the right way.

In this post I am going to explain my approach using as much of camunda ready-to-use functionality to avoid overhead.

Situation: Jack needs holidays and leaves for a week. John, the substitute, jumps in. He now has to deal with all of Jacks existing and newly created tasks.

A simple approach often working fine is to postpone user assignment to the very last second before a user task is created. This can be done by some piece of code e.g. asking ldap for help.

diagram_1-1

But what about tasks already assigned to Jack? How can John get them to show up in his task list? The above mentioned solution does not work here.
The solution I was thinking of had to handle the following requirements:

  1. assign new user tasks to the substitute collegue(s)
  2. assign already existing user tasks to the substitute collegue(s)
  3. holiday jack still can access all of his tasks (including new ones)
  4. do not iterate over every single task and update the assignee

This is what I did: Instead of filling the assignee field of a user task during process modelling I made use of candidate groups. A candidate group contains all the users that have the right to work on a task.

task-2

For simplicity, lets call the candidate group „jacks_tasks“. You can create it in camunda cockpit or using camunda’s identity service at runtime. Create a user Jack and add him to his own candidate group.
Something like this (using IdentityService):

Group jacksGroup = identityService.newGroup("jacks_tasks");
identityService.saveGroup(jacksGroup);

User jack = identityService.newUser("Jack");
identityService.saveUser(jack);

identityService.createMembership(jack, jacksGroup);

I used a listener on task creation which ran the code in order to set up group and user straight before assignment.

To make sure Jack gets his task list filled (while not on holidays) you don’t query for him as assignee but task candidate user (even the effort of refactoring this in an existing project isn’t that bad):

List<Task> list = taskService.createTaskQuery().taskCandidateUser("Jack").list();

Note: the user Jack here is just a simple camunda user even without permission to log into camunda task list. Use any (external) user id you prefer and/or need in order to retrieve usertasks.

Now comes the substitution part

Create (even on the fly) a user John, add him to the candidate group jacks_tasks and John will have access to all of Jacks tasks immediately with this single configuration step.

User john = identityService.newUser("John");
identityService.saveUser(john);
identityService.createMembership(john, jacksGroup);

You don’t need to iterate over dozens of tasks and update the assignee! Add more users to the group if John needs backup. Jack (member of the group) still can access his tasks. Nice and shiney.

Further thoughts:

  1. Yes I know, it is not very likely that Jack just leaves the office without notice. But think about a scenario where he calls in sick…
    But still, what about a foreseeable absence coming up? For that purpose we built a self-service for Jack and his collegues to configure substitution for a certain timespan. A util process takes care of the rest:
    scheduler
  2. To prevent the camunda workflow engine from containing tons of generated users without any task (and hence purpose), you could clean up users and candidate groups in intervals/at process end. Take a look at this:
//get all users in jacks_tasks
List<User> userList = identityService.createUserQuery().memberOfGroup("jacks_tasks").list();

for (User user : userList) {
  List<Task> list = taskService.createTaskQuery().taskCandidateUser(user.getId()).list();
  //delete user if he has not tasks atm
  if(list.size() == 0){
    identityService.deleteUser(user.getId());
  }
}

List<Task> list = taskService.createTaskQuery().taskCandidateGroup("jacks_tasks").list();
//delete group if it has no tasks atm
if(list.size() == 0){
  identityService.deleteGroup(groupId);
}

check out and run the code

Please find the code on blog.frena.de

process

Let me know if I can help you to understand this better. This was just a rough nutshell.

Veröffentlicht unter BPM & System Integration | Kommentar hinterlassen