LordLamer
  • Home
  • About Me
  • Familie
  • Knowledgeroot
  • Impressum
KEEP IN TOUCH

Posts in category Company

Von ACL zu ABAC: Eine Reise durch moderne Zugriffskontrolle

Feb06
2025
Written by lordlamer

Als wir kürzlich in unserem Procurement-System vor der Herausforderung standen, Berechtigungen für Belege zu implementieren, wurde mir wieder einmal bewusst, wie komplex moderne Zugriffskontrolle sein kann. In diesem Artikel möchte ich meine Erfahrungen mit verschiedenen Zugriffskontrollmodellen teilen und erklären, warum wir uns letztendlich für ABAC entschieden haben.

Die Grenzen klassischer ACLs

Wer kennt sie nicht – die guten alten Access Control Lists (ACLs)? Sie sind wie eine einfache Türliste am Eingang eines exklusiven Clubs: Entweder du stehst auf der Liste, oder eben nicht. In unserem Procurement-Kontext bedeutete das ursprünglich: Beleg XY – Zugriff für Nutzer A, B und C.

Anfangs erschien das ausreichend, aber schnell wurde klar: So einfach ist unsere Geschäftswelt nicht mehr. Was ist, wenn ein Mitarbeiter nur Belege seiner Abteilung sehen darf? Oder nur Belege unter 10.000€? Mit ACLs würde das bedeuten, für jeden Beleg einzeln festzulegen, wer Zugriff hat – ein administrativer Alptraum.

Der Zwischenschritt: RBAC

Role-Based Access Control (RBAC) war der logische nächste Schritt. Statt einzelnen Nutzern direkt Rechte zuzuweisen, definierten wir Rollen wie “Einkäufer”, “Abteilungsleiter” oder “Finanz-Controller”. Das vereinfachte die Administration erheblich – neue Mitarbeiter bekamen einfach die passende Rolle zugewiesen.

Aber auch RBAC stieß an seine Grenzen. Ein Beispiel: Ein Abteilungsleiter sollte nur Belege seiner eigenen Abteilung freigeben können, aber gleichzeitig alle Belege unter 1.000€ sehen dürfen. Mit RBAC müssten wir dafür mehrere spezifische Rollen erstellen – “Abteilungsleiter-IT”, “Abteilungsleiter-HR” etc. – oder komplexe Rollenhierarchien aufbauen.

ABAC: Die flexible Lösung

Attribute-Based Access Control (ABAC) war für uns die Erleuchtung. ABAC berücksichtigt nicht nur den Nutzer und seine Rollen, sondern auch:

  • Attribute des Objekts (z.B. Belegwert, Abteilung, Status)
  • Attribute des Nutzers (z.B. Position, Kostenstelle, Standort)
  • Umgebungsbedingungen (z.B. Uhrzeit, Netzwerk)
  • Aktionen (Lesen, Schreiben, Freigeben)

Ein Beispiel aus unserer Implementierung: “Ein Abteilungsleiter kann Belege freigeben, wenn:

  • der Beleg seiner Abteilung zugeordnet ist
  • der Belegwert unter seinem Freigabelimit liegt
  • der Beleg den Status ‘Zur Freigabe’ hat
  • es innerhalb der Geschäftszeiten ist”

Fazit: Komplexität vs. Flexibilität

Die Implementierung von ABAC war definitiv aufwändiger als die vorherigen Ansätze. Wir mussten:

  • Eine Policy-Engine einführen
  • Attribute-Verwaltung implementieren
  • Regelwerk sorgfältig definieren

Aber die gewonnene Flexibilität war den Aufwand wert. Änderungen an Zugriffsregeln können nun zentral in Policies verwaltet werden, ohne den Code anzufassen. Neue Geschäftsanforderungen lassen sich durch das Hinzufügen neuer Attribute und Regeln umsetzen, statt neue Rollen oder ACLs zu erstellen.

Für komplexe Enterprise-Anwendungen wie unser Procurement-System ist ABAC meiner Meinung nach alternativlos. Die anfängliche Komplexität wird durch die langfristige Flexibilität mehr als aufgewogen.

Free Branch Analysis in SonarQube Cummunity Edition – Here’s How!

Feb02
2025
Written by lordlamer

Hey there! Are you using SonarQube Community Edition and missing the branch analysis feature that’s only available in the paid versions? Don’t worry – I’ll show you how to add this functionality to your setup. With a community plugin and Docker, you’ll have it running in no time!

Quick Disclaimer First

Before we dive in, a quick heads-up: The plugin we’ll be using isn’t officially from SonarSource – it’s a community project under the GNU LGPL v3 license. If you’re planning to use this for large, business-critical projects, you might want to check out the official Developer Edition. But for most projects, this solution works perfectly fine!

What You’ll Need

– Docker and Docker Compose installed on your machine
– Git
– A Bash shell (Git Bash works fine on Windows)
– Basic Docker knowledge is helpful

Let’s Get Started!

1. Setting Up the Project

First, create a directory for your project:

mkdir sonarqube-docker
cd sonarqube-docker

2. Configuration Files

Let’s start with the .env file. This is where you set the versions you want to use:

SONARQUBE_VERSION=24.12.0.100206-community
BRANCH_PLUGIN_VERSION=1.23.0

Next up is the docker-compose.yml. It’s a bit longer, but don’t worry – you won’t need to modify anything:

services:
  sonarqube:
    depends_on:
      db:
        condition: service_healthy
    build:
      context: .
      dockerfile: Dockerfile
      args:
        - SONARQUBE_VERSION=${SONARQUBE_VERSION}
        - BRANCH_PLUGIN_VERSION=${BRANCH_PLUGIN_VERSION}
    container_name: sonarqube
    ports:
      - "9000:9000"
    networks:
      - sonarnet
    environment:
      - SONAR_JDBC_URL=jdbc:postgresql://db:5432/sonar
      - SONAR_JDBC_USERNAME=sonar
      - SONAR_JDBC_PASSWORD=sonar
    volumes:
      - sonarqube_conf:/opt/sonarqube/conf
      - sonarqube_data:/opt/sonarqube/data
  db:
    image: postgres:16
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U sonar" ]
      interval: 10s
      timeout: 5s
      retries: 5
    hostname: db
    container_name: postgres
    networks:
      - sonarnet
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data

volumes:
  sonarqube_conf:
  sonarqube_data:
  postgresql:
  postgresql_data:

networks:
  sonarnet:

Now for the Dockerfile – this is where we integrate the plugin into the SonarQube image:

ARG SONARQUBE_VERSION
FROM sonarqube:${SONARQUBE_VERSION}
ARG BRANCH_PLUGIN_VERSION
# Copy the plugin
COPY plugins/sonarqube-community-branch-plugin-${BRANCH_PLUGIN_VERSION}.jar /opt/sonarqube/extensions/plugins/
ARG PLUGIN_VERSION
ENV PLUGIN_VERSION=1.23.0
ENV SONAR_WEB_JAVAADDITIONALOPTS="-javaagent:./extensions/plugins/sonarqube-community-branch-plugin-${PLUGIN_VERSION}.jar=web"
ENV SONAR_CE_JAVAADDITIONALOPTS="-javaagent:./extensions/plugins/sonarqube-community-branch-plugin-${PLUGIN_VERSION}.jar=ce"

3. Helper Scripts

The download-plugin.sh script automatically fetches the plugin for you:

#!/bin/bash
mkdir -p plugins
curl -L -o plugins/sonarqube-community-branch-plugin-${BRANCH_PLUGIN_VERSION}.jar \
 https://github.com/mc1arke/sonarqube-community-branch-plugin/releases/download/${BRANCH_PLUGIN_VERSION}/sonarqube-community-branch-plugin-${BRANCH_PLUGIN_VERSION}.jar

And the start.sh script makes launching everything super easy:

#!/bin/bash
# Check if .env exists
if [ ! -f .env ]; then
    echo "Error: .env file not found!"
    exit 1
fi
# Load and export environment variables
export $(cat .env | grep -v '^#' | xargs)
# Check if required variables are set
if [ -z "$SONARQUBE_VERSION" ] || [ -z "$BRANCH_PLUGIN_VERSION" ]; then
    echo "Error: Required environment variables are not set!"
    echo "Please check SONARQUBE_VERSION and BRANCH_PLUGIN_VERSION in .env file"
    exit 1
fi
# Download plugin
./download-plugin.sh
# Start Docker Compose
docker-compose up -d

4. Almost There!

Make the scripts executable:

chmod +x download-plugin.sh start.sh

5. Launch Time!

Now just run the start script:

./start.sh

The script takes care of everything for you:
– Checks if all settings are correct
– Downloads the plugin
– Starts the Docker containers

6. Your SonarQube is Ready

After a few seconds, you can access SonarQube:
– URL: http://localhost:9000
– Login: admin
– Password: admin (you’ll need to change this on first login)

Using Branch Analysis

Now you can use branch analysis in your projects. Just specify the branch name when running a scan:

sonar-scanner \
-Dsonar.projectKey=my-awesome-project \
-Dsonar.branch.name=feature/new-feature

Common Issues and Solutions

1. SonarQube won’t start? Check the logs:

docker-compose logs sonarqube

2. On Linux, you might need this setting:

sudo sysctl -w vm.max_map_count=262144

3. Plugin not found? Check the plugins directory:

ls -l plugins/

Wrapping Up

That’s all there is to it! You now have a fully functional SonarQube installation with branch analysis. I’m using this setup myself for various projects and it works great.

Remember: For larger enterprises, the Developer Edition might be the better choice. But for most projects, this solution is more than adequate!

Useful Links

– The Community Branch Plugin on GitHub
– Official SonarQube Documentation
– SonarQube on Docker Hub

Posted in docker, Software Architektur

Der Weg zur besseren Software-Architektur – Ein Erfahrungsbericht

Nov18
2024
Written by lordlamer

Als Software-Entwickler stehe ich täglich vor der Herausforderung, die richtige Balance zwischen technischer Exzellenz und praktischer Umsetzbarkeit zu finden. In diesem Artikel möchte ich meine Erfahrungen teilen, wie man eine nachhaltige und wartbare Software-Architektur entwickeln kann, auch unter realen Bedingungen und Zeitdruck.

Die Grundlagen: Die richtigen Fragen stellen

Bevor wir uns in die technischen Details stürzen, sollten wir uns zunächst die wichtigsten Fragen stellen:

  • Welches konkrete Problem soll die Software lösen?
  • Wer ist die Zielgruppe und wie groß ist diese?
  • Welche Änderungen oder Erweiterungen sind in Zukunft zu erwarten?

Diese fundamentalen Fragen ermöglichen es uns, erste architektonische Entscheidungen zu treffen. Ein Beispiel aus unserer Praxis: Wir entwickeln Zusatzsoftware zur Datenextraktion aus ERP-Systemen. Da diese Software nicht direkt von Endbenutzern bedient wird, können wir hier andere architektonische Maßstäbe anlegen als bei einer benutzerorientierten Anwendung.

Die häufigsten Fallstricke

In meiner täglichen Arbeit beobachte ich immer wieder verschiedene Gründe für suboptimale Architekturentscheidungen:

  • Fehlendes fachliches Wissen
  • Zu viele technische Abhängigkeiten
  • Mangelndes technisches Know-how
  • Unzureichende Dokumentation
  • Fehlende Tests

Lösungsansätze aus der Praxis

1. Strukturierte Dokumentation mit Arc42

Eine meiner wichtigsten Erkenntnisse: Arc42 als Dokumentationsframework kann wahre Wunder bewirken. Es hilft uns dabei:

  • Software in überschaubare “Boxen” zu unterteilen
  • Probleme systematisch herunterzubrechen
  • Abhängigkeiten zwischen Anwendungsteilen klar zu definieren

Noch bevor die erste Zeile Code geschrieben wird, haben wir damit eine klare Zieldefinition für unsere Applikation.

2. Fachlichkeit vor Technik

Ein weiterer entscheidender Punkt ist die Priorisierung: Die fachliche Implementierung sollte immer vor der technischen Umsetzung stehen. Konkret bedeutet das:

  • Erst das fachliche Problem verstehen und lösen
  • Technische Implementierungsdetails bewusst zurückstellen
  • Test-Driven Development (TDD) nutzen, um fachlichen Code zu validieren

3. Kontinuierliche Weiterbildung

Entwickler sollten sich intensiv mit modernen Konzepten auseinandersetzen:

  • Domain-Driven Design (DDD)
  • SOLID-Prinzipien
  • Clean Code-Praktiken

Diese Konzepte helfen dabei, Architekturentscheidungen besser zu verstehen und nachhaltigere Software zu entwickeln.

Der Umgang mit Zeitdruck

Eine realistische Betrachtung des Zeitfaktors ist essentiell. Dabei gibt es zwei Perspektiven:

  1. Die Entwicklerseite: Wir wissen, dass Entwickler oft schlecht in Aufwandsschätzungen sind.
  2. Die Business-Seite: Kunden oder Unternehmen müssen Zeit und Geld investieren.

Mein Vorschlag: Statt nur nach Entwicklerschätzungen zu fragen, sollten wir auch die Gegenfrage stellen: “Wieviel sind Sie bereit zu investieren, um dieses Feature zu bekommen?” Diese Herangehensweise führt oft zu produktiven Diskussionen und realistischeren Erwartungen.

Fazit: Der Weg zur besseren Architektur

Zusammenfassend lassen sich folgende Kernpunkte festhalten:

  • Fokus auf fachliche statt technische Probleme
  • Technische Implementierungen so spät wie möglich festlegen
  • Strukturierte Dokumentation (z.B. mit Arc42) nutzen
  • Kontinuierlicher Aufbau von fachlichem und technischem Know-how
  • Einsatz moderner Entwicklungspraktiken wie TDD

Der Weg zu einer besseren Software-Architektur ist nicht einfach, aber er lohnt sich. Bei uns im Team sehen wir bereits deutliche Fortschritte, und ich bin zuversichtlich, dass wir auf dem richtigen Weg sind.

Dieser Artikel basiert auf meinen persönlichen Erfahrungen in der Software-Entwicklung. Ich freue mich über Ihre Gedanken und Erfahrungen zu diesem Thema!

Posted in Software Architektur

VxRail Vortrag

Oct20
2018
Written by lordlamer

Ich durfte kürzlich als Gastredner auf einer GID-IT-Veranstaltung unsere Erfahrungen zur Einführung von VxRail preis geben. Hier ein paar Fotos davon…



 

SUSE Certified Administrator

Jul12
2018
Written by lordlamer

So, ab jetzt darf ich mich auch SUSE Certified Administrator für SLES 12 schimpfen.

Die Prüfung war diesmal was ganz neues. Es wurden nur praktischen Aufgaben abgearbeitet. Nichts mit Multiple-Choice. Das gefiel mir ganz gut.

Hab dann auch mit 90% bestanden 😀

Posted in Linux, sap

Lancom Zertifiziert

May17
2018
Written by lordlamer

Im April hatte ich die Chance auf einen Lancom Workshop zu gehen und habe am Ende auch noch die Zertifizierung abgelegt. Ab jetzt bin ich auch Lancom Zertifiziert 😉

SAP Schulung in Kopenhagen

Mar16
2016
Written by lordlamer

Hier ein paar Bilder von der SAP Schulung aus Kopenhagen letzte Woche.

Eines sei noch erwähnt: SAP is the FUTURE 😀 (haha)












Posted in Familie, misc, sap

log2mail nicht mehr in Debian Stable

Sep11
2013
Written by lordlamer

Log2mail ist ein kleines Programm welches Log-Dateien mittels Regulären Ausdrücken überwacht und dann E-Mails versenden kann.

Leider ist dieses wunderbare kleine Programm aus Debian Wheezy geflogen und wird es wohl auch in Zukunft nicht weiter in den Stable Zweig schaffen.
Darum habe ich mich nach kurzer Recherche nach Alternativen(die leider einige Probleme hatten – tenshi)dazu entschlossen mit einem Kollegen die aktuelle Version zu nehmen und sie auf Debian Wheezy lauffähig zu machen. Das Ergebnis gibt es auf Github:
https://github.com/lordlamer/log2mail

Damit könnt ihr sofort loslegen und euer Paket für Wheezy selber bauen.

 

Posted in Debian, Linux

Jetzt auch Zend Certified Engineer PHP5.3

Sep11
2013
Written by lordlamer

Seit dem 17. Juli darf ich mich nun auch Zend Certified Engineer für PHP 5.3 nennen. Mit anderen Worten: Ich konnte nachweisen, dass ich mit PHP umgehen kann.

Das heißt, ich habe wieder ein hübsches Zertifikat bekommen neben einen tollen Aufkleber und ich darf jetzt das Certified Logo verwendne wie hier zu sehen.

Und hier auch nochmal das Zertifikat.

php-cert

Posted in Familie

Citrix Certified Administrator for Citrix XenApp 6

Jul24
2012
Written by lordlamer

Seit einigen Wochen hatte ich mich ja auf die Prüfung für Citrix Xenapp 6.5 vorbereitet. Am Dienstag letzter Woche habe ich dann auch die Prüfung gemacht und auch bestanden. Somit bin ich dann jetzt offiziell Citrix Certified Administrator for Citrix XenApp 6.

Und hier noch das Zertifikat dazu:

Posted in citrix
« Older Entries

Community

  • Forum
  • GitHub
  • Knowledgeroot
  • YouTube

Categories

  • bsd (1)
  • citrix (3)
  • Company (27)
  • Debian (11)
  • docker (1)
  • Familie (75)
  • Geocaching (2)
  • Hausbau (41)
  • IPv6 (5)
  • Java (4)
  • klettern (10)
  • Knowledgeroot (16)
  • Linux (12)
  • LUG Balista (1)
  • misc (22)
  • mysql (1)
  • netscreen (2)
  • postgresql (1)
  • sap (4)
  • Software Architektur (2)
  • solr (2)
  • vim (2)

EvoLve theme by Theme4Press  •  Powered by WordPress LordLamer
Frank Habermann

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok