SlideShare ist ein Scribd-Unternehmen logo

Regulatorics: Offside is when the referee whistles - DOAG 2018

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.

1 von 32
Downloaden Sie, um offline zu lesen
Torsten Kleiber, DOAG 2018 Nürnberg, 21.11.2018
Regulatorik: Abseits ist, wenn der Schiedsrichter pfeift
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
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
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
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.
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.
Anzeige

Recomendados

Das dreckige Dutzend - ADF Migration nach 12c in der IKB - DOAG 2014.
Das dreckige Dutzend - ADF Migration nach 12c in der IKB - DOAG 2014.Das dreckige Dutzend - ADF Migration nach 12c in der IKB - DOAG 2014.
Das dreckige Dutzend - ADF Migration nach 12c in der IKB - DOAG 2014.Torsten Kleiber
 
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017Torsten Kleiber
 
Qualitätssicherung in ADF Projekten der IKB Deutschen Industriebank AG
Qualitätssicherung in ADF Projekten der IKB Deutschen Industriebank AGQualitätssicherung in ADF Projekten der IKB Deutschen Industriebank AG
Qualitätssicherung in ADF Projekten der IKB Deutschen Industriebank AGTorsten Kleiber
 
Agile Oracle database modeling and development - APEX Connect 2020
Agile Oracle database modeling and development - APEX Connect 2020Agile Oracle database modeling and development - APEX Connect 2020
Agile Oracle database modeling and development - APEX Connect 2020Torsten Kleiber
 
Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen
Bob the Builder - Build & Deploy von ADF Enterprise AnwendungenBob the Builder - Build & Deploy von ADF Enterprise Anwendungen
Bob the Builder - Build & Deploy von ADF Enterprise AnwendungenTorsten Kleiber
 
Our way to 19c - DOAG 2020
Our way to 19c - DOAG 2020Our way to 19c - DOAG 2020
Our way to 19c - DOAG 2020Torsten Kleiber
 
Ü̈ber Ant und Maven zu SBT und Gradle
Ü̈ber Ant und Maven zu SBT und GradleÜ̈ber Ant und Maven zu SBT und Gradle
Ü̈ber Ant und Maven zu SBT und Gradleadesso AG
 
EntwicklerCamp 2014 - DOTS reloaded
EntwicklerCamp 2014 - DOTS reloadedEntwicklerCamp 2014 - DOTS reloaded
EntwicklerCamp 2014 - DOTS reloadedRené Winkelmeyer
 

Más contenido relacionado

Was ist angesagt?

Java magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollJava magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollWolfgang Weigend
 
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertRequirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertGFU Cyrus AG
 
Softwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration ToolsSoftwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration ToolsGFU Cyrus AG
 
Einführung in Puppet und Vagrant
Einführung in Puppet und VagrantEinführung in Puppet und Vagrant
Einführung in Puppet und Vagrants0enke
 
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...GFU Cyrus AG
 
May the forge be with you
May the forge be with youMay the forge be with you
May the forge be with youSandro Sonntag
 
JSF meets JS (2. ed.) - JSF-Komponenten mit JavaScript
JSF meets JS (2. ed.) - JSF-Komponenten mit JavaScriptJSF meets JS (2. ed.) - JSF-Komponenten mit JavaScript
JSF meets JS (2. ed.) - JSF-Komponenten mit JavaScriptOPEN KNOWLEDGE GmbH
 
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...gedoplan
 
Von Maven zu Gradle in 45 Minuten
Von Maven zu Gradle in 45 MinutenVon Maven zu Gradle in 45 Minuten
Von Maven zu Gradle in 45 MinutenQAware GmbH
 
Server Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerServer Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerSandro Sonntag
 
C/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersC/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersUlrich Krause
 
Article - JDK 8 im Fokus der Entwickler
Article - JDK 8 im Fokus der EntwicklerArticle - JDK 8 im Fokus der Entwickler
Article - JDK 8 im Fokus der EntwicklerWolfgang Weigend
 
Cross-Apps-Entwicklung für iPhone, Android und Co.
Cross-Apps-Entwicklung für iPhone, Android und Co.Cross-Apps-Entwicklung für iPhone, Android und Co.
Cross-Apps-Entwicklung für iPhone, Android und Co.GFU Cyrus AG
 
Continuous Integration mit Hudson (JUG Stuttgart, 11.02.2010)
Continuous Integration mit Hudson (JUG Stuttgart, 11.02.2010)Continuous Integration mit Hudson (JUG Stuttgart, 11.02.2010)
Continuous Integration mit Hudson (JUG Stuttgart, 11.02.2010)Wiest Simon
 
Gameduell Glassfish Migration
Gameduell Glassfish MigrationGameduell Glassfish Migration
Gameduell Glassfish Migrationdehms
 
Zend Framework
Zend FrameworkZend Framework
Zend Frameworkluckec
 
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...gedoplan
 

Was ist angesagt? (20)

Java magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollJava magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_voll
 
Die Java Plattform Strategie
Die Java Plattform StrategieDie Java Plattform Strategie
Die Java Plattform Strategie
 
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertRequirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
 
Softwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration ToolsSoftwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration Tools
 
Einführung in Puppet und Vagrant
Einführung in Puppet und VagrantEinführung in Puppet und Vagrant
Einführung in Puppet und Vagrant
 
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
 
May the forge be with you
May the forge be with youMay the forge be with you
May the forge be with you
 
JSF meets JS (2. ed.) - JSF-Komponenten mit JavaScript
JSF meets JS (2. ed.) - JSF-Komponenten mit JavaScriptJSF meets JS (2. ed.) - JSF-Komponenten mit JavaScript
JSF meets JS (2. ed.) - JSF-Komponenten mit JavaScript
 
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
 
Von Maven zu Gradle in 45 Minuten
Von Maven zu Gradle in 45 MinutenVon Maven zu Gradle in 45 Minuten
Von Maven zu Gradle in 45 Minuten
 
Server Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerServer Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM Server
 
C/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersC/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino Developers
 
Article - JDK 8 im Fokus der Entwickler
Article - JDK 8 im Fokus der EntwicklerArticle - JDK 8 im Fokus der Entwickler
Article - JDK 8 im Fokus der Entwickler
 
Cross-Apps-Entwicklung für iPhone, Android und Co.
Cross-Apps-Entwicklung für iPhone, Android und Co.Cross-Apps-Entwicklung für iPhone, Android und Co.
Cross-Apps-Entwicklung für iPhone, Android und Co.
 
Continuous Integration mit Hudson (JUG Stuttgart, 11.02.2010)
Continuous Integration mit Hudson (JUG Stuttgart, 11.02.2010)Continuous Integration mit Hudson (JUG Stuttgart, 11.02.2010)
Continuous Integration mit Hudson (JUG Stuttgart, 11.02.2010)
 
Gameduell Glassfish Migration
Gameduell Glassfish MigrationGameduell Glassfish Migration
Gameduell Glassfish Migration
 
Zend Framework
Zend FrameworkZend Framework
Zend Framework
 
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
Das Runde muss in das Eckige - Java-Anwendungen für Kubernetes entwickeln und...
 
Jenkins Acceleration
Jenkins AccelerationJenkins Acceleration
Jenkins Acceleration
 
Best Practices 
Java und JVM in Containern
Best Practices 
Java und JVM in ContainernBest Practices 
Java und JVM in Containern
Best Practices 
Java und JVM in Containern
 

Ähnlich wie Regulatorics: Offside is when the referee whistles - DOAG 2018

Continous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickelnContinous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickelnMartin Seibert
 
Digicomp change management_2 0_m_schweizer_v3_150317
Digicomp change management_2 0_m_schweizer_v3_150317Digicomp change management_2 0_m_schweizer_v3_150317
Digicomp change management_2 0_m_schweizer_v3_150317Markus Schweizer
 
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Virtual Forge
 
BATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern
 
Log4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfLog4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfStephan Kaps
 
Vortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development EnvironmentsVortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development EnvironmentsThorsten Kamann
 
MEAN SCS in der Cloud
MEAN SCS in der CloudMEAN SCS in der Cloud
MEAN SCS in der CloudTorsten Fink
 
Skalierung & Performance
Skalierung & PerformanceSkalierung & Performance
Skalierung & Performanceglembotzky
 
Zeitnahe Reaktion auf Verordnungsänderungen mit Feature Toggles
Zeitnahe Reaktion auf Verordnungsänderungen mit Feature TogglesZeitnahe Reaktion auf Verordnungsänderungen mit Feature Toggles
Zeitnahe Reaktion auf Verordnungsänderungen mit Feature TogglesBATbern
 
DACHNUG50 Die Domino REST API - Konzepte und Hintergruende.pdf
DACHNUG50 Die Domino REST API - Konzepte und Hintergruende.pdfDACHNUG50 Die Domino REST API - Konzepte und Hintergruende.pdf
DACHNUG50 Die Domino REST API - Konzepte und Hintergruende.pdfDNUG e.V.
 
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-CodequalitätFotiosKaramitsos
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...Aberla
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsFabian Niesen
 
Microservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenMicroservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenJan Thielscher
 
Git vs SVN - Eine vergleichende Einführung
Git vs SVN - Eine vergleichende EinführungGit vs SVN - Eine vergleichende Einführung
Git vs SVN - Eine vergleichende EinführungMario Müller
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDNUG e.V.
 

Ähnlich wie Regulatorics: Offside is when the referee whistles - DOAG 2018 (20)

CDI
CDICDI
CDI
 
Continous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickelnContinous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickeln
 
Digicomp change management_2 0_m_schweizer_v3_150317
Digicomp change management_2 0_m_schweizer_v3_150317Digicomp change management_2 0_m_schweizer_v3_150317
Digicomp change management_2 0_m_schweizer_v3_150317
 
Referat: Change Management 2.0
Referat: Change Management 2.0Referat: Change Management 2.0
Referat: Change Management 2.0
 
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
 
BATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu Microservices
 
Log4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfLog4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdf
 
Vortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development EnvironmentsVortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development Environments
 
MEAN SCS in der Cloud
MEAN SCS in der CloudMEAN SCS in der Cloud
MEAN SCS in der Cloud
 
Skalierung & Performance
Skalierung & PerformanceSkalierung & Performance
Skalierung & Performance
 
Camunda BPM 7.2 - Deutsch
Camunda BPM 7.2 - DeutschCamunda BPM 7.2 - Deutsch
Camunda BPM 7.2 - Deutsch
 
Zeitnahe Reaktion auf Verordnungsänderungen mit Feature Toggles
Zeitnahe Reaktion auf Verordnungsänderungen mit Feature TogglesZeitnahe Reaktion auf Verordnungsänderungen mit Feature Toggles
Zeitnahe Reaktion auf Verordnungsänderungen mit Feature Toggles
 
DACHNUG50 Die Domino REST API - Konzepte und Hintergruende.pdf
DACHNUG50 Die Domino REST API - Konzepte und Hintergruende.pdfDACHNUG50 Die Domino REST API - Konzepte und Hintergruende.pdf
DACHNUG50 Die Domino REST API - Konzepte und Hintergruende.pdf
 
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
 
Microservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenMicroservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen sollten
 
Hey, wie geht es dir?
Hey, wie geht es dir?Hey, wie geht es dir?
Hey, wie geht es dir?
 
Git vs SVN - Eine vergleichende Einführung
Git vs SVN - Eine vergleichende EinführungGit vs SVN - Eine vergleichende Einführung
Git vs SVN - Eine vergleichende Einführung
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
 

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
  • 13. Multi-Branch-Pipelines 13 Änderungen durchlaufen die Pipeline, nur in Master-/Release-Branches erfolgt Deployment.
  • 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
  • 16. Commits/Push Developmentprozess: Grafisch Issue Feature-/Bugfix- Branch Pull Request Code Review Merge Build Feature-/Bugfix- Branch Build Pull Request Build Master-/Relase Branch Deploy Master-/Relase Branch Integrations-Test Acceptance-Test Produktion Code Master Master Master, Release Build Feature-/Bugfix- Branch SOA Composites Integrations-Test 16
  • 17. Erzeugen eines Feature Branches Aus dem JIRA Issue wird ein Branch angelegt, der direkt in Jenkins gebaut wird. 17
  • 18. automatischer Build des Branchs Nach dem Push von Commits läuft ein weiterer Build des Branches in Jenkins an. 18
  • 19. Anlegen Pull Request 19 Üblicherweise vom letzten Entwickler wird der Pull Request angelegt.
  • 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