Head of DevOps, SRE & Security (DevSecOps)
Group CTO für 145 Personen in sechs Ländern und weiterhin operativ im Detail. Zahlungsinfrastruktur für eine Zentralbank, eine KI-Agentenplattform auf drei Clouds, zehn A100 auf Bare Metal und zwei Zertifizierungen, die das Audit bestanden haben.
- 99,999 %bei Bakong, dem Zahlungssystem der Nationalbank von Kambodscha
- 0 Befundeim ISO-27001-Überwachungsaudit; SOC 2 Type II zweimal bestanden
- 145 Personenin sechs Ländern, mit direkter Berichtslinie an den CEO
Werdegang
Was ich verantwortet habe
Acht Bereiche, ein Nachweisstandard
Führung
145 Personen · 6 LänderGroup CTO · Head of DevOps, SRE & Security
Führung
145 Personen · 6 Länder- Die gesamte Organisation berichtete an mich, mit Standorten in Japan, Russland, der Schweiz, Montenegro, Thailand und Dubai. Ich selbst berichtete an den CEO.
- Zuerst die technische Organisation aufgebaut: auf dem Höchststand 37 direkte Unterstellte, davon 12 DevOps, 6 Security und 19 QA.
- Bei Everworker: Neuaufbau ohne Tooling, Prozesse oder Stellen. Ein vierköpfiges Security-Team aufgebaut.
Zahlungsverkehr & CBDC
99,999 %Bakong · CBDC-Pilotprojekte
Zahlungsverkehr & CBDC
99,999 %- Zuverlässigkeit und Sicherheit für Bakong, das Zahlungssystem der Nationalbank von Kambodscha, in Java auf Hyperledger Iroha entwickelt.
- 2024 über 150 Mrd. US-Dollar abgewickelt, rund 330 % des kambodschanischen BIP, und 2025 1,3 Milliarden Zahlungen, laut Veröffentlichung der NBC.
- CBDC-Pilotprojekte in der gesamten Gruppe. Beteiligt an Central Bankings „CBDC Partner of the Year“, 2020.
Plattform & KI
300+ Apps · 99 % IaCAWS · Azure · GCP · Bare Metal
Plattform & KI
300+ Apps · 99 % IaC- Eine KI-Agentenplattform auf drei Clouds, ausgeliefert als SaaS und selbst gehostet in den eigenen Konten der Kunden.
- AWS-Marketplace-Listing mit Helm-Charts für drei Clouds, im Alleingang umgesetzt, nachdem es hieß, dafür brauche es bezahlte Partner. AWS Marketplace
- 10 × NVIDIA A100 auf Bare Metal bei Moro Hub, Dubai (Tier III), nachdem eine vergessene GPU-Instanz in zwei Tagen Tausende Dollar verbrannt hatte.
- Über 300 Anwendungen, über 700 Repositories, 6 GitHub-Organisationen. Build-Zeiten um 40 % gesenkt, Kosten um über 30 %.
Zuverlässigkeit
MTTR −60 %SRE-Praxis von Grund auf aufgebaut
Zuverlässigkeit
MTTR −60 %- Eingebettetes SRE für über 20 Stream-aligned Teams in 4 Regionen: SLIs, SLOs, Error Budgets, Incident Command, Blameless Reviews.
- SLA von 99 % auf 99,99 % angehoben. Automatisierte Backups und DR für 5 geschäftskritische Systeme, die Wiederherstellungen wurden tatsächlich durchgeführt.
- Eine Rufbereitschaft, mit der Menschen leben können: täglicher Dienstplan, auf jeder Schicht eine Vertretung, zu jedem Alert ein Runbook und eine Metrik.
Sicherheit & Assurance
0 Befunde im ÜberwachungsauditISO 27001 · SOC 2 Type II · NIST CSF
Sicherheit & Assurance
0 Befunde im Überwachungsaudit- ISO/IEC 27001:2022: die 5 geringfügigen Abweichungen des Erstaudits geschlossen, anschließend das Überwachungsaudit im ersten Jahr ohne Befunde bestanden. Trust Center
- SOC 2 Type II zwei Jahre in Folge bestanden, Umfang um Privacy und Availability erweitert. Das NIST-CSF-Programm auf Kundenwunsch geleitet.
- Secure SDLC für über 100 Entwickler: STRIDE- und VAST-Bedrohungsmodelle, CVSS- und EPSS-Bewertung, Security Champions. Expositionsfenster um 70 % verkürzt.
- Unabhängiger Penetrationstest: 12 Befunde (1 hoch, 6 mittel, 5 niedrig) triagiert; die wichtigsten wurden zu DAST-Regressionschecks, bleiben also unter Test.
Produkte
2 Produkte · 2 × 12 Personendurchgängig verantwortet
Produkte
2 Produkte · 2 × 12 Personen- Ein Zahlungssystem für karibische Inseln, mit eigenem zwölfköpfigem Team.
- Ein Bonuspunktesystem für ein großes Ökosystem, mit eigenem zwölfköpfigem Team.
Web3
dieselben Gates wie bei ZahlungssystemenPolkadot · Klaytn · SORA
Web3
dieselben Gates wie bei Zahlungssystemen- Web3-Foundation-Grants, Entwicklung im Polkadot-Ökosystem, Klaytn und das SORA-Ökosystem, auf denselben Pipelines und Security Gates wie die Zahlungssysteme.
- Vortrag auf der Next-Generation Payments 2023 und auf Fintech-Konferenzen in Bangkok.
Incident-Reviews
Aus Incident Response, Audits und der Arbeit an Kundenplattformen. Jeder Fall endete in einer Kontrolle, nicht in einem Patch.
Abfluss von Quellcode und Erpressungsversuch
87.000 Ereignisse analysiert
- Erkannt
Auffällige Aktivitäten in Repositories.
- Untersucht
Forensik über einen Audit-Export mit 87.000 Ereignissen. Die Reichweite der Zugangsdaten wurde erneut getestet, nicht angenommen.
- Behoben
Eindämmung und Zurücksetzen der Zugangsdaten, danach der organisationsweite Zugriff als Pulumi-IaC neu aufgebaut, damit manuelle Freigaben nicht zurückkehren können.
Eine Credential-Rotation, die das Monitoring nicht sehen konnte
0 Daten verloren · am selben Tag behoben
- Erkannt
Auf einer Kundenplattform rotierte die verwaltete Datenbank planmäßig ihr Master-Passwort, und die Anwendung verlor über Nacht die Datenbankverbindung. Kein Alert ging los.
- Untersucht
Die App las das Passwort nur einmal, beim Deploy. Eine Prüfung der Alarmierung ergab, dass jede Regel auf ihre Art blind war: Der Prozess lief weiter, die Fehlerschwellen lagen über dem, was dieser Traffic selbst bei Totalausfall erreicht, und der Pool-Alert führte es auf langsame Queries zurück.
- Behoben
Am selben Tag: Die App wechselte auf eine Rolle mit minimalen Rechten und einem Passwort, das das Team besitzt, und ein Deploy schlägt nun fehl, wenn sich diese Zugangsdaten nicht anmelden können. Neue Alerts bei leerem Pool, Health-Endpunkt, Verbindungsuntergrenze und fehlendem Backup. Es gingen keine Daten verloren.
Webhooks, die bei jeder vierten Anfrage scheiterten
upstream für alle Nutzer behoben
- Erkannt
Auf einer Kundenplattform traten bei etwa einem Viertel der POST-Requests Webhook-500er, nicht passende Signaturen und CSRF-Fehler auf, nachdem sich ein Upstream-Image unter dem gepinnten Release geändert hatte.
- Untersucht
Chunked-Bodies kamen leer in der App an: Sie liest den Body über Content-Length, und eine Chunked-Anfrage hat keins. Die 500er wurden nirgends geloggt, weil das Standard-Logging des Frameworks sie bei ausgeschaltetem Debug verschluckte.
- Behoben
Request-Buffering ist jetzt der Standard im Open-Source-Deployment-Tool, die App setzt Chunks auf WSGI-Ebene wieder zusammen, Webhooks antworten nie mit 5xx, und Fehler landen in strukturierten Logs.
Connection refused, jeweils 14 Sekunden lang
0 von 7.254 Probes fehlgeschlagen
- Erkannt
Endnutzer einer Kundenplattform meldeten abgelehnte Verbindungen auf Port 443. Der Cloud-Autoscaler hatte den Edge-Proxy an dem Tag 37-mal verdrängt, davor 0- bis 8-mal am Tag.
- Untersucht
Der Proxy drainte 10 Sekunden; der Load Balancer brauchte etwa 24, um den Node auszutragen. Mit einer Probe im Halbsekundentakt reproduziert: ein 14-Sekunden-Fenster, in dem etwa die Hälfte der neuen Verbindungen scheiterte.
- Behoben
Länger drainen als der Health-Check, Proxys strikt über Hosts verteilt, beide Einstellungen im Open-Source-Tool ergänzt. 0 Fehlschläge bei 7.254 Probes über mehrere Rollouts.
Ein Release-Prozess mit überspringbarem Schritt
Deploys jetzt ganz oder gar nicht
- Erkannt
Auf einer Kundenplattform lief Produktion 20 bis 30 Minuten ohne ihren Prozessor für Hintergrundaufgaben, während die Uptime grün blieb: Der Worker war nicht deployt worden, es gab also nichts, worauf ein Alarm anschlagen konnte.
- Untersucht
Der Release beruhte auf zwei getrennten manuellen Schritten, erst Web, dann Worker, und nichts prüfte, ob beide gelaufen waren. Checks vor dem Merge und Admission Control wurden ausgeschlossen: Git war korrekt, und der Worker wurde nie eingereicht.
- Behoben
Aufgeteilte Services werden jetzt als ein geordneter Workflow deployt, der rot wird, wenn nicht beide Hälften erfolgreich sind, und das separate Worker-Deployment wurde entfernt. Paritäts-Alerts bleiben als Absicherung.
Alarmierung, der niemand vertraute
89 % Fehlalarme → 0
- Erkannt
232 CloudTrail-Alarme in 14 Tagen, etwa 89 % Fehlalarme.
- Behoben
8 Detektoren über die CIS-Baseline hinaus, mit Ausnahmen pro Detektor: einstellige Alarmzahl pro Tag, keine Fehlalarme im ersten Zeitfenster, ein Runbook für jeden Alert.
Der Wachhund, der nicht mehr wachte
hängende Läufe lösen sich jetzt selbst
- Erkannt
Der Dead-man's Switch eines Kunden war stillschweigend ausgefallen: 4,5 Tage lang endete jeder geplante Lauf abgebrochen.
- Untersucht
Ein Lauf, den die CI-Plattform in der Queue liegen ließ, hielt seine Concurrency Group für immer fest. Timeouts greifen nicht, bevor ein Job gestartet ist, also wartete jeder spätere Lauf und wurde dann abgebrochen. Es trat innerhalb eines Tages wieder auf.
- Behoben
Kurze geplante Workflows brechen jetzt den laufenden Lauf ab, sodass ein hängender Lauf vom nächsten ersetzt statt blockiert wird.
52 % höhere Rechnung bei 4 % CPU
11 gepinnte Nodes → 5-9 nach Bedarf
- Erkannt
Kostenreview auf einer Kundenplattform: Die Prognose stieg in einem Monat um 52 %, bei 18 Nodes mit etwa 4 % CPU-Last.
- Untersucht
Das Standard-Disruption-Budget des Deployment-Tools ließ Single-Replica-Services null erlaubte Evictions, sodass der Autoscaler nie einen Node leeren konnte. Jedes neue White-Label hielt einen weiteren fest.
- Behoben
Ein Budget mit einer erlaubten Eviction, über 13 Repositories ausgerollt. Produktion sank von 11 festgehaltenen Nodes auf 5-9 nach Bedarf, Staging von 7 auf 3. Den Wechsel des Upstream-Defaults habe ich zurückgehalten: zu viele angesammelte Änderungen für eine Zahlungs-Produktion.
Ein ISMS, das Werkzeuge anführte, die das Unternehmen nicht besaß
29 Richtlinien geprüft
- Erkannt
29 übernommene, KI-entworfene Richtlinien, die MDM, EDR und Verzeichnisdienste nannten, die nicht existierten.
- Behoben
Die Prüfung jedes genannten Tools und jeder genannten Rolle ist vor der Freigabe nun verpflichtend. KI entwirft, Belege entscheiden.