  | Diesen Newsletter im Web lesen | |  | Microsoft-Dienste ohne Cloud +++ Neues Post-Exploitation-Framework AdaptixC2 +++ Wie viel CO₂ steckt in der Software? +++ Schnelle KI-Bildanalyse im Browser +++ Security Operations mit n8n automatisieren +++ Cisco Live Protect für Switches
|
| |
|
| Liebe Leserin, lieber Leser,
|
| wer seine Daten in der Azure-Cloud hat, will sie sicher wissen – und das heißt verschlüsselt. Die Gretchenfrage lautet: Reichen die Microsoft-Schlüssel oder sollen es lieber eigene sein? Azure bietet da Optionen und Kombinationsmöglichkeiten, aber das Angebot ist nicht leicht zu überblicken. Unser Titelautor Achim Berberovic erklärt, wie man es angehen kann und wo man unbedingt Herr der Schlüssel sein sollte. Einen Überblick aller Themen des neuen Hefts finden Sie im Inhaltsverzeichnis der iX 3/2026.
| |
|
|
| |
|
|
| | | | Strukturierter verschlüsseln in Azure | |
| |
| |
Armin Berberovic ist Senior IT Security Architect in der Luftfahrtindustrie. Seine mehrjährige Erfahrung im Bereich Sicherheit für Cloud und cloudnative Techniken teilt er in seinem Blog cloudsec42.com.
Axel: Von Pressemitteilungen über Terminkalender bis hin zu Geschäftsgeheimnissen halten Unternehmen so einiges an Daten vor. Wie kann man da strukturiert Schutzklassen bestimmen?
Armin: Maßgeblich für die Einordnung von Daten in eine Schutzklasse ist der Schaden, den diese Daten in den falschen Händen verursachen können. Üblich ist hier eine Einteilung in öffentliche, interne, vertrauliche und streng vertrauliche Daten. Eine Pressemitteilung wäre ein Beispiel für eine öffentliche Information, die das Unternehmen aus freien Stücken mit der Allgemeinheit teilt. Da ist nicht zu erwarten, dass ein Angreifer mit diesen Informationen das Unternehmen schädigen kann. Anders sieht das aus, wenn Geschäftsgeheimnisse erbeutet werden. Hier droht nicht nur ein Imageverlust, auch die Erpressung durch kriminelle Banden oder eine Schwächung der eigenen Wettbewerbsfähigkeit liegt im Spektrum der möglichen Folgen.
Axel: Verschlüsselung ist natürlich auch eine Frage des Schlüssels. Ab wann sollte man auf eigene Schlüssel setzen, wann sind vielleicht auch die von Microsoft verwalteten akzeptabel?
Armin: Zum Schutz öffentlicher und interner Daten sind von Microsoft verwaltete Schlüssel ausreichend. Sie erfordern wenig Aufwand und sind kostengünstig. Das ist wie so oft in der IT-Sicherheit eine Ermessensentscheidung, bei der Kosten und Aufwände den potenziellen Schäden gegenüberzustellen sind. Hier sollte weder mit Kanonen auf Spatzen geschossen noch am falschen Ende gespart werden, weshalb spätestens ab der Schutzklasse „vertraulich“ die Verwaltung der Schlüssel in die eigenen Hände zu nehmen ist.
Axel: Was empfiehlt sich an zusätzlichen Maßnahmen für die höchste Vertraulichkeitsstufe?
Armin: Unerlässlich für streng vertrauliche Daten ist der Einsatz eines Hardware Security Modules (HSM). Ein HSM ist ein dediziertes Hardware-Modul, das kryptographische Operationen mithilfe eines integrierten Mikroprozessors ausführt und dort verwahrten Schlüsseln einen besonderen Schutz bietet. So verfügt es über zusätzliche Sicherheitsmechanismen, die aktiv auf Manipulationsversuche reagieren. Wird ein solcher Versuch festgestellt, können die gespeicherten Schlüssel gelöscht oder das HSM deaktiviert werden. Damit bieten HSMs einen besseren Schutz vor Manipulationen als rein software-basierte Schutzmaßnahmen.
|
| |
|
|
| |
|
| |
|
|
| | Armin Berberovic (links) im Gespräch mit iX-Redakteur Axel Kannenberg
|
|
| |
|
| |
|
| |
Axel: Wie wird die Verwendung eigener Schlüssel bei Azure implementiert?
Armin: Azure nutzt ein mehrstufiges Verschlüsselungsverfahren, welches als Envelope Encryption bekannt ist. Diese Technik kennt zwei Schlüssel, den Key Encryption Key (KEK) und einen Data Encryption Key (DEK). Mit dem KEK wird, wie der Name bereits verrät, ein zweiter Schlüssel verschlüsselt, etwa um den zweiten Schlüssel sicher irgendwo abzulegen. Dieser als „wrapping“ bekannte Prozess wird auf den DEK angewendet, mit dem die Daten verschlüsselt sind.
Soll eine Datei entschlüsselt werden, muss zunächst mit dem KEK der DEK „unwrapped“ (entschlüsselt) werden, um mit dem DEK dann die Datei zu entschlüsseln. Bei einem selbstverwalteten Schlüssel in Azure handelt es sich um den KEK. Dieser kann in Azure Key Vault wahlweise mit softwarebasiertem Schutz oder im Premium-Tier auch in einem HSM abgelegt und über diverse Schnittstellen mit anderen Azure-Diensten genutzt werden. Dabei schützt er in seiner Funktion als KEK den DEK, mit den der jeweilige Dienst seine Daten verschlüsselt.
Axel: Welche Optionen bietet Azure im Feld der Hardware-Security-Module?
Armin: Über Key Vault hinaus bietet Azure mit Managed HSM, Cloud HSM und Payment HSM weitere Möglichkeiten, einen KEK mittels HSM zu schützen. Mit diesen Alternativen ist gut beraten, wer sich ein dediziertes HSM wünscht und dem Key Sovereignty besonders wichtig ist. Key Sovereignty meint die alleinige Kontrolle über die Erstellung, Löschung und Verwaltung der Schlüssel im HSM, die auch Microsoft-Mitarbeiter aus dem Kreis der Zugriffsberechtigten exkludiert. Alle drei Angebote verfügen über beide Features und unterscheiden sich hauptsächlich darin, wie Wartung, Updates und die Ausfallsicherung gehandhabt werden. Außerdem lassen sich mit Azure Payment HSM spezielle Anwendungsfälle abbilden, welche bei der Verarbeitung von Kreditkarten hilfreich sind.
|
| |
|
|
| |
|
| |
|
|
| | | | Im Heft geschmökert: Empfehlungen der iX-Redaktion | |
| |
|
| |
| | | | Viele Unternehmen, gerade kleinere, haben wenige Ressourcen, was sie spätestens bei einem Cyberangriff schmerzlich spüren. In Baden-Württemberg gibt es seit geraumer Zeit die Idee der Cyberbündnisse – also Absprachen zwischen Unternehmen, sich im Ernstfall zu helfen. Diese kann man in unterschiedlichen Verbindlichkeitsstufen realisieren. Der baden-württembergische Verband Allianz Industrie 4.0 hat dazu einen nützlichen Praxisleitfaden herausgegeben. Positiver Nebeneffekt der Cyberbündnisse: Selbst wenn es zu keinem Vorfall kommt, profitieren die Unternehmen. Denn durch die Vorbereitungen erhöhen sie ihre Resilienz gegen Angriffe und verbessern die NIS2-Konformität.
Ute Roos, Redakteurin iX
|
| |
|
|
|---|
|
| |
|
| |
|
| | | | Selbstverständlich keine Zahlung beim Cyberangriff mit Ransomware – das ist die allgemeine Devise. Doch wenn Produktivbetrieben nach wenigen Tagen Stillstand der Bankrott droht und die Wiederherstellung zu lange dauert, wirkt ein Lösegeld trotzdem wie das kleinere Übel. Im Interview berichtet Incident Responder Patrick Münch, welcher Verhandlungsspielraum in solch einem Fall offen steht, worauf er bei der Kommunikation achtet – und wie er geforderte Summen sogar drücken konnte.
Kornelius Kindermann, Redakteur iX
|
| |
|
|
|---|
|
| |
|
| |
|
|
| | | | Workshop-Tipp: Backstage für Admins – Internal Developer Platform aufbauen und betreiben | |
| |
| | Dieser zweitägige Workshop richtet sich an Administratoren und DevOps-Engineers, die Backstage als Internal Developer Platform (IDP) im Unternehmen einführen und betreiben möchten. Im Fokus stehen Aufbau, Konfiguration und Betrieb einer zentralen Plattform, die Entwicklungs-, Test- und Produktionsumgebungen sowie CI/CD, Monitoring, Logging und Zugriffsmanagement gebündelt bereitstellt. Die Teilnehmer lernen, Backstage fachlich zu bewerten, bereitzustellen und anzupassen, Entwicklungsumgebungen und Container-Images zu erstellen, den Software-Katalog und Templates zu nutzen, Backstage mit Kubernetes zu verknüpfen sowie die Plattform über Plugins und TechDocs zu erweitern. Ziel ist der Aufbau einer zentralen Self-Service-Plattform für Entwickler.
|
| |
| |
|
| |
|
| |
|
|
| | | | Weitere Themen in der iX 3/2026 | |
| |
| | Außerdem zeigen wir in der neuen iX, wie das grafische Automationstool Power Automate den Admins Routineaufgaben erleichtert, ordnen ein, was das Ende des Ingress-Controllers für die Kubernetes-Welt bedeutet, und zeigen die Sicherheitsrisiken beim Client-Side-Scanning der viel debattierten Chatkontrolle. Alle Themen finden Sie im Inhaltsverzeichnis der iX 3/2026.
Haben Sie Anregungen zum Newsletter oder zum Heft allgemein? Schreiben Sie mir unter axk@ix.de! Ich wünsche Ihnen einen März, in dem es Ihnen nie an Schlüsselkompetenzen mangelt, Ihr
|
|
| |
|
| |
| | Neugierig geworden? Sie erhalten die iX 3/2026 ab dem 19. Februar im heise Shop und ab dem 20. Februar am Kiosk:
|
| |
|
| |
|
| |
| Sie sind unter folgender Adresse eingetragen: unknown@unknown.invalid - .
Hier können Sie sich von künftigen Zusendungen abmelden.
| |
| Verantwortlich für den Inhalt:
Heise Medien GmbH & Co. KG
Karl-Wiechert-Allee 10
30625 Hannover
Telefon: +49 [0]511 5352-0
E-Mail: infoservice@heise.de
Registergericht:
Amtsgericht Hannover HRA 26709
|
| | Persönlich haftende Gesellschafterin:
Heise Medien Geschäftsführung GmbH
Registergericht:
Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Beate Gerold
|
|
|---|
|
| |
| Herausgeber: Christian Heise, Ansgar Heise
Chefredakteur: Dr. Oliver Diedrich (verantwortlich)
Alle Rechte vorbehalten. Jegliche Vervielfältigung oder Weiterverbreitung in jedem Medium als Ganzes oder in Teilen bedarf der schriftlichen Zustimmung des Verlags. Copyright © 2026 Heise Medien GmbH & Co. KG
| |
|
| |
|
|
