The regulatory system has more and more influence on our software development.
Regulatory authorities, external and internal Auditors are increasingly examining our IT and not longer only our business processes and balance sheets. Some of them have better trained IT experts as we can find on the free market.
General standards such as ISO/IEC 2700X but also banking-specific standards such as BAIT and MaRisk now pose challenges that generally only large software manufacturers know. Approximately 40 % of our projects are now regulatory-driven.
Therefore, we are currently redefining our development process in order to implement the following requirements, among others * Unchangeability of the tested artefacts after the test * Functional segregation * Detection of accidental changes or intentional manipulations of the application
The lecture shows the vision of such a safe process. It shows the current status of implementation in SOA and ADF development, for example:
Migration of version management to GIT in Atlassian BitBucket
Application and selection criteria for a branching model
Mandatory code reviews in Atlassian BitBucket
Build and Deployment Pipelines in Jenkins
Automatic documentation in JIRA Issue via Bitbucket and Jenkins.
Maybe you too can minimize the additional work and continue to work agile to meet such requirements.
Regulatorics: Offside is when the referee whistles - DOAG 2018
1. Torsten Kleiber, DOAG 2018 Nürnberg, 21.11.2018
Regulatorik: Abseits ist, wenn der Schiedsrichter pfeift
2. IKB – Die Unternehmerbank
IKB im Überblick
Bank für den Mittelstand
Mid Caps Deutschland
Mid Cap-Wachstum deutlich höher als deutsche Volkswirtschaft
Starkes inländisches Umsatzwachstum mit hohem Potenzial für internationale
Expansion
Operative Margen über den Konjunkturzyklus hinweg widerstandsfähig
2
Umsatzwachstumspotenzial, Mid Caps Deutschland
Unterdurchschnittlich
DurchschnittlichHochSehr hoch
IKB-Standorte
Einzig bundesweit agierende Bank, die ausschließlich Firmenkunden begleitet
Starke Kreditexpertise
Langjährige Erfahrung im Fördermittelkreditgeschäft
Kapitalmarkt- und Beratungsdienstleistungen
Zugang zu mehr als 4.000 Fokuskunden
Finanzierungspartner für Mittelstand seit mehr als 90 Jahren
817 Mitarbeiter (VAK)
Aktionär: Lone Star 100 %
Bilanzsumme: 17,2 Mrd. €
CET 1 Ratio: 11,6 % fully loaded
Leverage Ratio: 7,0 % fully loaded
3. Abseits ist, wenn der Schiedsrichter pfeift
Franz Beckenbauer
Die Abseitsstellung eines Spielers stellt an sich noch kein Vergehen dar.
Ein Spieler befindet sich in einer Abseitsstellung, wenn er der gegnerischen
Torlinie näher ist als der Ball und der vorletzte Gegenspieler
Ein Spieler befindet sich nicht in einer Abseitsstellung
in seiner eigenen Spielfeldhälfte oder
auf gleicher Höhe mit dem vorletzten Gegenspieler oder
auf gleicher Höhe mit den beiden letzten Gegenspielern«
Abseits im Fußball
Der (eine) Schiedsrichter kann das Abseits nur pfeifen, wenn der Spieler aktiv am Spiel
teilnimmt oder einen Vorteil aus der Abseitsposition zieht
1) https://upload.wikimedia.org/wikipedia/commons/7/74/Franz_Beckenbauer_2007.jpg
2) https://gfds.de/13-abseits-ist-wenn-der-schiedsrichter-pfeift/
3
4. Abseits in der Softwareentwicklung
Mehr Schiedsrichter als Spieler bringen die IT ins Abseits, teilweise bereits bevor sie aktiv
wird und auch wenn noch kein nachgewiesener Nachteil entstanden ist.
4
Grundschutzkataloge
ISO/IEC 2700X
PrüfungenPrüfungen
BAIT
MaRisk
GDPR / DSGVO
Gesetzgeber und Behörden Aufsichtsbehörden
Wirtschaftsprüfer Interne Prüfer (Revision, Security,
Datenschutz)
Prüfungen
IT
5. Beispiel: Aufgabentrennung
5
Quelle Beschreibung
BAIT 5 Das Institut hat insbesondere das Informationsrisikomanagement, das Informations-
sicherheitsmanagement, den IT-Betrieb und die Anwendungsentwicklung quantitativ
und qualitativ angemessen mit Personal auszustatten.
BAIT 6 Interessenkonflikte und unvereinbare Tätigkeiten innerhalb der IT-Aufbau- und IT-
Ablauforganisation sind zu vermeiden. Interessenkonflikten zwischen Aktivitäten, die
beispielsweise im Zusammenhang mit der Anwendungsentwicklung und den
Aufgaben des IT-Betriebs stehen, kann durch aufbau- oder ablauforganisatorische
Maßnahmen bzw. durch eine adäquate Rollendefinition begegnet werden.
Interne
Revision
Einzelne Entwickler übernehmen die Administration der Systeme und besitzen auf Ebene
des Betriebssystems und der Datenbank- und Applikationsserver weitreichende
Berechtigungen. Administrative Berechtigungen von Entwicklern auf Datenbank- und
Serverebene sowie in Deployment-Tools sind zu entziehen.
Administration in Entwicklungsteam ist möglich, wenn Personen nur noch diese Rolle
ausüben oder über Code Review geprüft werden. Fehlende Kapazitäten sind aufzubauen.
6. Beispiel: Anwendungsentwicklung
Diese Anforderungen sind nicht mehr rein organisatorisch lösbar ohne in eine Nachweis-
pflicht zu geraten. Im folgenden wird die Umsetzung bei der IKB beschrieben.
6
Quelle Beschreibung
BAIT 39 Im Rahmen der Anwendungsentwicklung müssen Vorkehrungen getroffen werden, die
erkennen lassen, ob eine Anwendung versehentlich geändert oder absichtlich
manipuliert wurde. Eine geeignete Vorkehrung unter Berücksichtigung des
Schutzbedarfs kann die Überprüfung des Quellcodes im Rahmen der
Anwendungsentwicklung sein.
Interne
Revision
In den Deployment-Tools besteht die Möglichkeit für Entwickler, nach Abnahme
Codebestandteile zu verändern und ohne weitere Kontrollen in Produktion zu bringen.
Es ist sicherzustellen, das der Code nach der Abnahme nicht mehr verändert
werden kann.
7. KreDa (Kredit und Darlehensverwaltung und vieles mehr)
Ausgangslage Architektur KreDa, Versionierung, Branching, Build & Deploy
7
Oracle Forms & Reports
PVCS, kaum Branches, UC4
Oracle ADF
Subversion, langlebige Feature
Branches & Cherry Picking, Jenkins
Jobs
Oracle PL/SQL / Views
PVCS, kaum Branches, UC4
Oracle SOA
Suite Mediator
Subversion,
langlebige
Feature
Branches &
Cherry Picking,
Jenkins Jobs
Oracle Datenbank
PVCS, keine Branches, UC4
AndereAnwendungen
8. Neues Version Control System (VCS): Git + Atlassian Bitbucket
Übernahme Einzel-Commits bei Merge inklusive Autor zur Änderungsdokumentation
Unterstützung und Erzwingen Code Review
VCS-Server mit Administrationsoberfläche
Konfigurierbares Branching Modell
Dezentrale Versionierung lokal bei Entwickler
Schneller Zugriff
Migration von Subversion nach Git über Atlassian-Tools
Client Git für Windows und Atlassian Sourcetree
JDeveloper Git-Client nicht komfortabel
SSO noch nicht umgesetzt
Migrationsunterstützung für Serena PVCS Version Manger
Einführung von GIT und Bitbucket ist die Voraussetzung für folgende Tools und Prozesse.
8
9. Monorepo: Technologien in selben Code-Repository, Entwicklung in einem Branch/Issue möglich
Trunk Based Development
Code beginnend mit dem Integrationstest im master (=trunk) eingecheckt
kein Cherry Picking, Änderungen laufen durch alle Umgebungen
kurzlebige Feature-/Bugfix-Branches
Release-Branches für Bugfixes
Feature Toggles / Branch by Abstraction
Monorepo und Trunk Based Development sind Standards
Isolierte kleinteilige Issues erforderlich, Abhängigkeiten beachten!
Features vollständig beschrieben vor Entwicklungsbeginn, sonst lokales RAD mit Kunde erforderlich
Neue Anforderungen sind neue Issues!
Abnahmeverpflichtung Fachbereich vor Merge erforderlich, dann erst Deployment/Test
Fehlende Abnahme Reverse Merge neuer Regressions-Test
Git-Struktur/Branching-Modell sind Voraussetzung für die Umsetzung. Durch die
erforderliche neuen Prozesse ändern sich auch massiv die Prozesse der Fachbereiche!
Branching Strategie: Trunk Based Development auf Basis eines Monorepo
9
10. Monorepo
Alle für ein Feature erforderlichen Änderungen sind in einem Issue/Branch durchführbar.
10
11. Trunk Based Development
Änderungen durchlaufen für Deployment immer den Master. Ausnahme: Sonderfälle bei
Bugfixes (z.B. bei geändertem Datenmodell evtl.. auf Master nicht mehr testbar)
11
Ablauf zeitlich nach unten und Umgebung nach rechts
Branches
- master (=Subversion Trunk)
- feature/bugfix für Entwicklung
- master, release/* nur über Pull Request änderbar
- master: fortlaufende Integration von Änderungen für
Test und Einsatz
- release: 1 letzter Produktionstand für Bugfixes
tags: durch Jenkins vergeben für
- Version: v<Jahr>.<Monat>.<Master>.<Bugfix>
- Umgebung
- e,a,p: Einsatztermin der Version pro Stage
- Entwicklung, Abnahme, Produktion:
Kennzeichnung des aktuellen Stands pro Stage
12. Pipelines: Buildprozess als Code eingecheckt in das Monorepo inklusive Code Review
Multi-Branch-Pipelines: Build für alle Branch-Typen und Pull Requests
- Pipeline einmalig vom Administrator in Jenkins geladen und konfiguriert
- Code durchläuft selbe Pipeline
- frühe Integration und Stabilität des Master-/Release-Branches durch Build Pull Reuests
- nur im Master-/Release-Branch erfolgen Deployments nach Abfrage durch autorisierte Benutzer
automatischer Start bei Änderung des Codes
Funktionstrennung durch administrative Ablage von Passworten etc. in Jenkins
Continuous Delivery Release jederzeit einsetzbar, wenn getestet
Jenkins Integration mit Atlassian JIRA und Bitbucket
Aufräumen überholter/alter Pipeline-Instanzen noch manuell, da Milestone-Plugin bug-behaftet
Jenkins Pipelines as Code: Multi-Branch-Pipelines
Build und Deployment ist als Code dokumentiert, versioniert und unterliegt dem Code
Review. Passworte der Laufzeit-Umgebung werden zur Funktionstrennung in Jenkins
abgelegt. Branches und Pull Requests werden automatisch gebaut.
12
14. Pipeline für ADF und SOA
In der Präsentation wird meist nur eine vereinfachte Demo-Pipeline gezeigt, das ist die
aktuelle reale Pipeline.
14
15. Code-Review: Atlassian Bitbucket über Pull Requests
Pull Requests dienen der Abstimmung und Freigabe von Änderungen
Code-Review und Merge sind konfigurierbar
Branches master und release/* nur durch Pull Requests änderbar
Merge-Cecks: mdst. 1 Reviewer erforderlich, Alle Reviewer stimmen zu, mdst. 2 erfolgreiche Builds
Ersteller des Pull Requests kann nicht Reviewer werden
Differenzsicht mit Kommentierungs-/Interaktions-Möglichkeiten
Reviewer muss den Pull Request vor dem Merge explizit als erfolgreich reviewed markieren
Merge kann jeder Berechtigte durchführen, also auch der Reviewer
Integriert mit Atlassian JIRA
Trunk Based Development o.ä. Branching Modell erforderlich
git push –author: abweichende Autoren verhindern eigenes Plugin entwickelt
Code Review ist Engpass separater Status im JIRA Kanban Board
Diff-Sicht bei Binärsourcen wie Oracle Forms & Reports?
Unabhängig von den Autoren der Einzel-Commits im Pull-Request sind mindestens 2
Personen für die Freigabe erforderlich
15
20. automatischer Build Pull Request
Nach kurzer Zeit läuft der erste Build des Pull Request in Jenkins an.
20
21. Review durch Anleger nicht möglich, Merge nicht möglich
Der Anleger kann sich nicht als Reviewer zuordnen, ein Merge ist noch nicht möglich.
21
22. als anderer Benutzer Zuordnung als Reviewer, Merge nicht möglich
Ein anderer Entwickler kann sich als Reviewer zuordnen, um das Review durchzuführen.
22
23. Korrektur von Code im Branch
Korrekturen im Branch aktualisiert den Pull Request und baut Branch und Pull Request.
23
24. Freigabe und Merge
Der Reviewer muss den Pull Request genehmigen, erst danach kann gemerged werden.
24
25. automatischer Build und Deployment des Master-Branchs
Der Build des Masters läuft an, wartet aber auf eine Bestätigung des Deployments.
25
26. Commit Historie mit Tags Master-Branch
26
Man sieht, wann die Version in welche Umgebung gegangen und ob sie noch aktuell ist.
27. Pull Request Historie Übersicht
Es werden Teil-Informationen über Merge-Ziel und Merge-Checks gezeigt.
27
28. Pull Request Historie Details
Es wird die gesamte Historie des Pull Requests gezeigt.
28
29. Entwicklungshistorie in JIRA-Issue
29
Commits und Pull Requests werden für jeden berechtigten JIRA User angezeigt, gelöschte
Branches nicht mehr. Für weitere Details benötigt man Berechtigungen in Bitbucket.
30. Fazit
Ausgangslage
Die Regulatorik stellt die IT ins Abseits, obwohl funktionierende Software geliefert wird.
Regulatorische Anforderungen
- stehen teilweise im Widerspruch zum Stand der Technik (z.B. DevOps)
- können mit weniger oder mehr Aufwand gelöst werden
Ziel: weitgehend automatisierte Lösungen, um den Mehraufwand für IT gering zu halten
Umsetzung der Beispielanforderungen
Funktionstrennung zwischen Entwicklung und Administration, Zugänge geändert
Entwicklungsprozess wurde geändert um
- sicherzustellen, das der Code nach dem Test nicht mehr verändert werden kann
- verpflichtend ein Code Review durchzuführen, um Schadcode frühzeitig zu erkennen
Tools und Prozesse wurden eingeführt und angepasst (Git; Git for Windows; Atlassian Bitbucket,
JIRA & Sourcetree; Monorepo & TBD; Jenkins Multibranch Pipelines as Code; Code Review)
Prozess ist für ADF- und SOA-Entwicklung produktiv, PL/SQL, Forms & Reports stehen noch aus
30
31. Über mich
Torsten Kleiber
Software-Architekt, Entwickler, DevOps, Administrator
Kreditplattform
Seit 19 Jahren bei der IKB
22 Jahre Erfahrung in
PL/SQL
Forms & Reports
ADF
SOA Mediator
Architektur & Infrastruktur
Fusion Middleware
Development Tools
Development Lifecycle
31