Decision Log

Dokumentierte Design-Entscheidungen und deren Begründungen. Jeder Eintrag folgt dem ADR-Format (Architecture Decision Record). Der Decision Log ist die Single Source of Truth für alle Abweichungen vom Concat Standard.

Warum ein Decision Log?

Ohne Decision Log	Mit Decision Log
„Warum ist das so konfiguriert?” — Keiner weiß es	Jede Entscheidung ist nachvollziehbar begründet
Im Handover geht Wissen verloren	Neuer Consultant liest den Log und versteht die Historie
Streitfälle („Das haben wir nie so besprochen”)	Schriftliche Dokumentation schützt Concat und den Kunden
Security-Audit fragt „Warum keine MFA hier?”	Antwort sofort parat inkl. Risikoübernahme

ADR-Vorlage

Jede Entscheidung wird als Architecture Decision Record (ADR) im folgenden Format dokumentiert:


## ADR-[NR]: [Titel]
 
**Status:** Akzeptiert | Abgelehnt | Veraltet | Ersetzt durch ADR-XXX
**Datum:** TT.MM.JJJJ
**Entscheider:** [Name/Rolle beim Kunden] + [Concat Consultant]
 
### Kontext
[Welches Problem wird adressiert? Was ist die Ausgangssituation?]
 
### Entscheidung
[Was wurde entschieden? Konkret und unmissverständlich.]
 
### Begründung
[Warum wurde so entschieden? Welche Alternativen wurden geprüft?]
 
### Konsequenzen
[Welche Auswirkungen hat die Entscheidung? Welche Risiken werden bewusst akzeptiert?]
 
### Verwandte ADRs
[Optional: Verweise auf zusammenhängende Entscheidungen]

Neues ADR anlegen

Neuen Eintrag mit der nächsten fortlaufenden Nummer erstellen. Titel kurz und aussagekräftig wählen.

Alle Felder ausfüllen

Besonders wichtig: Begründung und Konsequenzen. Ohne diese beiden Felder ist ein ADR wertlos.

Review und Freigabe

ADR wird vom Technical Lead reviewed. Bei sicherheitsrelevanten Entscheidungen zusätzlich vom Kunden schriftlich bestätigt.

Im Projekt-Wiki ablegen

ADR im Wiki des Kundenprojekts ablegen. Bei Concat-Standard-ADRs: hier in der zentralen Dokumentation.

Concat Standard-ADRs

Diese ADRs gelten für alle Kundenprojekte und definieren den Concat Standard:

ADR-001 bis ADR-003

ADR-001: Entra ID Join als Standard

Status: Akzeptiert
Datum: 01.01.2025
Entscheider: Concat Technical Board

Kontext: Kunden fragen häufig nach Hybrid Join, weil sie es „schon immer so gemacht haben”. Wir müssen einen klaren Standard definieren.

Entscheidung: Entra ID Join (Cloud-native) ist der Concat-Standard. Hybrid Join nur bei dokumentierter technischer Notwendigkeit (z. B. Legacy-Apps mit Kerberos-Abhängigkeit).

Begründung:

Cloud-native Geräte benötigen keine Sichtlinie zum Domain Controller → funktioniert im Home-Office
Alle modernen Features (Autopilot User-driven, WHfB Cloud Trust, LAPS via Entra) werden unterstützt
Deutlich geringere Komplexität (kein AD Connector, keine GPO-Konflikte, keine AD-Replikation)
Microsoft selbst empfiehlt Cloud-native als Ziel-Architektur

Konsequenzen:

Legacy-Apps, die Kerberos/NTLM-Authentifizierung benötigen, müssen über Cloud Kerberos Trust oder Entra Private Access angebunden werden
Lokale Printserver funktionieren nicht out-of-the-box → Universal Print oder IP-basiertes Drucken
Netzlaufwerke über GPO-Logon-Scripts → OneDrive KFM + SharePoint

ADR-002: Win32-Format als App-Packaging-Standard

Status: Akzeptiert
Datum: 15.01.2025
Entscheider: Concat Technical Board

Kontext: Intune unterstützt verschiedene Paketformate (MSI, MSIX, Win32, Store). Es fehlt ein einheitlicher Standard.

Entscheidung: Alle Desktop-Applikationen werden als Win32-App (.intunewin) verpackt.

Begründung:

Win32 bietet die meisten Steuerungsmöglichkeiten: Detection Rules, Requirement Rules, Dependencies, Supersedence
Flexibelstes Format — sowohl .exe als auch .msi Installer können gewrapped werden
ESP-Kompatibilität: Nur Win32-Apps können als blockierende Apps auf der Enrollment Status Page verwendet werden
Einheitliches Format vereinfacht die Schulung und das Troubleshooting

Konsequenzen:

Etwas höherer initialer Aufwand beim Packaging (IntuneWinAppUtil)
Etwas größerer Storage-Verbrauch im Intune Content Store
Siehe Packaging-Richtlinien

ADR-003: Open Intune Baseline als Security Standard

Status: Akzeptiert
Datum: 01.02.2025
Entscheider: Concat Technical Board

Kontext: Es gibt mehrere Security Baselines: Microsoft Intune Security Baselines, CIS Benchmarks, eigene Policies. Wir brauchen einen einheitlichen Standard.

Entscheidung: Die Open Intune Baseline (OIB) ist der Concat Security Standard für alle Kundenprojekte.

Begründung:

Open Source und transparent — jede Einstellung ist nachvollziehbar und auf GitHub dokumentiert
Vereint die besten Elemente aus NCSC, CIS, ACSC und Microsoft Best Practices
Berücksichtigt explizit User Experience und Admin-Verwaltbarkeit
Modularer Aufbau — einzelne Policies unabhängig anpassbar
Community-getrieben mit regelmäßigen Updates und Changelogs
Microsofts eigene Baselines sind zu monolithisch und oft disruptiv

Konsequenzen:

OIB muss bei jedem Kunden initial importiert werden (via IntuneManagement Tool)
OIB-Updates müssen aktiv verfolgt werden (GitHub Releases)
Kundenspezifische Anpassungen werden als separate Policies angelegt (OIB-Policies bleiben unverändert)
Siehe Security Baselines

ADR-004 bis ADR-006

ADR-004: Kein lokaler Admin für Endbenutzer

Status: Akzeptiert
Datum: 01.02.2025
Entscheider: Concat Technical Board

Kontext: Viele Kunden gewähren ihren Endanwendern standardmäßig lokale Admin-Rechte. Dies ist eines der größten Sicherheitsrisiken.

Entscheidung: Endbenutzer erhalten keine lokalen Administrator-Rechte. IT-Support nutzt Windows LAPS für temporären Admin-Zugriff.

Begründung:

Lokale Admin-Rechte ermöglichen die Installation von Malware, Schatten-IT und die Deaktivierung von Sicherheitsfeatures
Microsoft empfiehlt seit Jahren die Entfernung lokaler Admin-Rechte als Top-Security-Maßnahme
Windows LAPS bietet eine sichere, zeitlich begrenzte Alternative für den IT-Support
Für granulare Elevation (z. B. einzelne Programme als Admin starten) kann Endpoint Privilege Management (EPM) evaluiert werden

Konsequenzen:

User können keine eigene Software installieren → Company Portal als Alternative
IT-Support muss in LAPS geschult werden
Erwartbar: Initiale Beschwerden von Power-Usern → Change Management und Kommunikation
Siehe LAPS & Admin-Rechte

ADR-005: Windows Autopatch als Update-Standard

Status: Akzeptiert
Datum: 15.02.2025
Entscheider: Concat Technical Board

Kontext: Kunden mit E3/E5-Lizenzen können Windows Autopatch nutzen. Alternative: Manuelle WUfB Update-Ringe.

Entscheidung: Windows Autopatch ist der Standard für Kunden mit Microsoft 365 E3/E5. Bei Business Premium: Manuelle Update-Ringe (WUfB).

Begründung:

Autopatch automatisiert den gesamten Update-Lifecycle (Test → Pilot → Broad)
Inkl. Treiber-Management und Feature-Updates
Microsoft übernimmt die Überwachung und Eskalation bei Update-Problemen
Deutlich weniger operativer Aufwand für die IT

Konsequenzen:

Autopatch erfordert E3/E5 Lizenz (nicht verfügbar bei Business Premium)
Weniger granulare Kontrolle als bei manuellen Update-Ringen
Kunden mit speziellen Anforderungen (z. B. extrem konservative Patch-Zyklen) → manuelle Ringe
Siehe Patch Management

ADR-006: VPP für alle Apple-Apps

Status: Akzeptiert
Datum: 01.03.2025
Entscheider: Concat Technical Board

Kontext: Apple-Apps können über VPP (Volume Purchase) oder direkt über den App Store installiert werden.

Entscheidung: Alle Apple-Apps werden über VPP (Apple Business Manager) beschafft und via Intune zugewiesen.

Begründung:

VPP ermöglicht Silent App Push ohne Apple ID auf dem Gerät
Zentrale Lizenzverwaltung und App-Updates über Intune
Ohne VPP muss sich der User mit einer persönlichen Apple ID anmelden → Datenschutz-Problem

Konsequenzen:

ABM muss eingerichtet sein (VPP-Token aktiv)
Auch kostenlose Apps müssen über VPP „gekauft” werden (0€)
Jährliche Token-Erneuerung erforderlich
Siehe Apple Business Manager

ADR-007 bis ADR-009

ADR-007: Per-App VPN statt Always-On VPN

Status: Akzeptiert
Datum: 01.03.2025
Entscheider: Concat Technical Board

Kontext: Kunden fragen häufig nach Always-On VPN. Wir müssen den Standard definieren.

Entscheidung: Per-App VPN ist der Standard. Always-On VPN nur bei dokumentierter Anforderung (z. B. strikte Compliance-Vorgaben).

Begründung:

M365-Traffic (Teams, Outlook, OneDrive) benötigt kein VPN — er geht direkt in die Microsoft Cloud
Per-App VPN tunnelt nur den Traffic von Legacy-/On-Prem-Apps → reduziert VPN-Last um 80%+
Bessere User Experience (kein VPN-Connect nötig bei Cloud-Nutzung)
Geringere Infrastrukturkosten (VPN-Concentrator wird weniger belastet)

Konsequenzen:

Nur definierte Apps nutzen den VPN-Tunnel
Erfordert saubere Definition der VPN-pflichtigen Apps
Bei Kunden mit „Tunnelblick” (alles muss durch den Tunnel) → Aufklärungsarbeit nötig

ADR-008: App Protection Policies für BYOD (kein MDM)

Status: Akzeptiert
Datum: 15.03.2025
Entscheider: Concat Technical Board

Kontext: Sollen private Geräte (BYOD) über MDM enrollt werden oder nur über App Protection Policies (MAM) geschützt werden?

Entscheidung: Private Geräte werden nicht per MDM enrollt. Schutz ausschließlich über App Protection Policies (MAM without Enrollment).

Begründung:

User akzeptieren kein MDM auf ihrem privaten Gerät → Adoption-Problem
DSGVO: Vollständiger MDM-Zugriff auf Privatgeräte ist datenschutzrechtlich problematisch
App Protection Policies schützen Firmendaten auf App-Ebene ausreichend (Copy/Paste-Block, Verschlüsselung, Selective Wipe)
Betriebsrat-Problematik: MDM auf Privatgeräten führt häufig zu Widerstand

Konsequenzen:

Kein Geräte-Level-Compliance-Check auf BYOD-Geräten
Jailbreak/Root-Detection nur auf App-Ebene (statt Geräte-Compliance)
Bei High-Security-Anforderungen: Firmengeräte statt BYOD
Siehe iOS BYOD und Android BYOD

ADR-009: Certificate Connector auch bei Cloud-only

Status: Akzeptiert
Datum: 15.03.2025
Entscheider: Concat Technical Board

Kontext: Der Intune Certificate Connector wird oft fälschlicherweise nur mit Hybrid-Szenarien assoziiert.

Entscheidung: Der Certificate Connector wird unabhängig vom Join-Typ deployt, sobald der Kunde 802.1X Netzwerkauthentifizierung (WLAN/LAN) oder zertifikatsbasiertes VPN nutzt.

Begründung:

802.1X hängt von der Netzwerkinfrastruktur ab, nicht vom Join-Typ
Auch reine Cloud-native Umgebungen (Entra ID Join) benötigen Zertifikate für WLAN-Authentifizierung
Die Trennung von AD Connector (nur Hybrid) und Certificate Connector (Netzwerk-abhängig) muss klar kommuniziert werden

Konsequenzen:

Im Discovery muss die Netzwerkinfrastruktur (802.1X, RADIUS/NPS) erfasst werden
Certificate Connector benötigt eine On-Prem Microsoft CA (ADCS)
Siehe Intune Connectoren

Kundenspezifische ADRs

Zusätzlich zu den Standard-ADRs werden in jedem Kundenprojekt kundenspezifische ADRs erstellt. Typische Beispiele:

ADR-Nr.	Beispiel-Titel	Grund
ADR-K001	Hybrid Join für Standort München	SAP-Server benötigt AD-Computer-Auth
ADR-K002	Chrome als zusätzlicher Browser	Kundenanforderung wegen Webapplikation
ADR-K003	PowerShell RemoteSigned statt AllSigned	Keine interne PKI vorhanden
ADR-K004	USB-Ausnahme für Medizingeräte	Branchenspezifisch (Gesundheitswesen)

Note

Kundenspezifische ADRs werden im Wiki des Kundenprojekts gepflegt — nicht in dieser zentralen Concat-Dokumentation. Die Nummerierung beginnt mit ADR-K001.