[{"content":"Als Fachinformatiker für Anwendungsentwicklung merke ich in der Praxis immer wieder: Code, der „nur“ funktioniert, ist erst die halbe Miete. Stabile Infrastrukturen, automatisierte Deployments und vor allem IT-Sicherheit sind keine reinen Ops-Themen mehr. Sie müssen von der ersten Codezeile an mitgedacht werden.\nMit diesem Journal starte ich meine eigene kleine Dokumentationsplattform. Mein Ziel ist es, meine Lernkurve an der Schnittstelle von Softwareentwicklung, DevSecOps und KI sichtbar zu machen. Ich möchte festhalten, welche Best Practices sich bewähren – und welche Fehler ich auf dem Weg mache.\nEigeninitiative und Proof-of-Concept: Mein Labor Theoretisches Wissen ist eine gute Basis, aber echte Erfahrung entsteht erst auf der Kommandozeile. Um neue Konzepte nicht nur zu lesen, sondern wirklich zu verstehen, nutze ich eine eigene Labor-Infrastruktur:\nDer Server: Ein eigener VPS (4 vCPUs, 8 GB RAM, 240 GB SSD) dient mir als dedizierte Umgebung für komplexe Deployments, Härtungsmaßnahmen und Pipeline-Tests. Die Umsetzung: Jedes Konzept wandert als direktes Projekt ins Labor. Die Konfigurationen, Ergebnisse und vor allem die Stolpersteine dokumentiere ich anschließend hier im Blog in Form von praxisnahen Write-ups. Mein Fahrplan für die nächsten Monate Damit ich zielgerichtet vorankomme, habe ich mir für die kommenden Monate eine klare technische Roadmap gesetzt. Die folgenden Bereiche bilden das inhaltliche Rückgrat meiner Projekte:\nGrundlagen, Netzwerke \u0026amp; Systemsicherheit Der Startpunkt ist eine solide Linux-Administration. Ich orientiere mich hier am ISC² Certified in Cybersecurity (CC) Standard. Praktisch starte ich mit der harten Absicherung meines Servers: Konsequentes SSH-Key-Only, Port-Filterung und UFW-Setups.\nWeb Application \u0026amp; API Security Wie greift man Anwendungen an und wie schützt man sie? Ich analysiere typische Schwachstellen nach den OWASP Top 10 und spiele die Szenarien in praxisnahen Labs (wie der PortSwigger Web Security Academy) durch.\nContainer-Hardening Docker-Deployments sind Standard, aber oft unsicher konfiguriert. Mein Fokus liegt hier auf dem Schutz des Host-Systems: Rootless Daemons, User Namespaces und der Einsatz minimaler Basis-Images.\nDevSecOps \u0026amp; CI/CD-Pipelines Sicherheit muss automatisiert passieren. Ich implementiere und teste Security-Checks direkt in GitHub Actions. Auf dem Plan stehen SAST (Source-Code-Analyse), SCA (Abhängigkeitsprüfung) und DAST (dynamische Tests).\nCloud-Infrastruktur \u0026amp; Identity Management Know-how-Aufbau in AWS und Microsoft Azure. Der Schwerpunkt liegt auf Identity \u0026amp; Access Management (IAM), dem Schreiben restriktiver Policies und der Benutzerverwaltung über Microsoft Entra ID.\nAusblick Dieser Blog ist in erster Linie ein Werkzeug für mich selbst: Wer Dinge so aufbereitet, dass andere sie verstehen, hat sie meistens auch selbst durchdrungen. Gleichzeitig hoffe ich, dass auch andere Entwickler, Admins oder IT-Entscheider hier nützliche Ansätze für moderne Architekturen und sichere Cloud-Umgebungen finden.\nFür Fragen, Feedback oder einfach einen fachlichen Austausch – lassen Sie uns gerne direkt auf LinkedIn vernetzen.\n","permalink":"https://cwillam.de/blog/posts/mein-erster-beitrag/","summary":"Als Fachinformatiker für Anwendungsentwicklung merke ich in der Praxis immer wieder: Code, der „nur“ funktioniert, ist erst die halbe Miete. Stabile Infrastrukturen, automatisierte Deployments und vor allem IT-Sicherheit sind keine reinen Ops-Themen mehr. Sie müssen von der ersten Codezeile an mitgedacht werden.\nMit diesem Journal starte ich meine eigene kleine Dokumentationsplattform. Mein Ziel ist es, meine Lernkurve an der Schnittstelle von Softwareentwicklung, DevSecOps und KI sichtbar zu machen. Ich möchte festhalten, welche Best Practices sich bewähren – und welche Fehler ich auf dem Weg mache.","title":"Start meines Tech \u0026 Security Journals: Warum ich meine Lernschritte dokumentiere"}]