- Anzeigen -


Sie sind hier: Home » Fachbeiträge » Grundlagen

Beschaffung von X.509-Zertifikaten


Sichere beschleunigte IT durch Automatisierung von Schlüsseln und Zertifikaten
Schlüssel und Zertifikate sind die Grundlage der Sicherung moderner SSL/TLS-basierter Datenkommunikationen

- Anzeigen -





Von Carl Bourne, Global Solutions Architect bei Venafi

In diesem Beitrag wird untersucht, wie der Lebenszyklus verschlüsselter, kritischer Assets in den dynamischen und schnellen IT-Umgebungen reibungslos und zentral per Richtlinie geregelt werden kann. Anhand eines sogenannten "Cookbooks" wird über die Beschaffung von X.509-Zertifikaten ein anspruchsvoller Anwendungsfall besprochen, bei dem es um die Frage geht, wie sich Plattformen für Automatisierungsprozesse im Management von digitalen Zertifikaten und kryptographischen Schlüsseln mit dem Chef-DevOps-Framework integrieren lassen. Die in diesem Anwendungsfall behandelten Grundsätze lassen sich einfach in fast alle anderen DvOps-Frameworks implementieren.

Die Kontrolle der Nutzung von Schlüsseln und X.509-Zertifikaten in der dynamischen Welt der Rechner, Container und Micro Services von heute führt zu neuen Herausforderungen, die wiederum ein neues Konzept erfordern. In dieser neuen Welt, die Wert auf schnelle Lieferung von Daten legt, kann Sicherheit nicht einfach mithilfe traditioneller, langsamer IT-Richtlinien und -Prozesse durchgesetzt werden.

Die Bereitstellungsgeschwindigkeit von IT-Services hat sich dramatisch beschleunigt
Geschäftskunden und IT-Experten verlangen neue IT-Services und -Umgebungen, die bedarfs- und zeitgerecht erstellt werden. Sie fordern für "interne" IT-Dienste ähnliche Fähigkeiten und Geschwindigkeiten, wie Amazon AWS und ähnliche Dienste sie bieten. Das Analystenhaus Gartner prognostiziert, dass bis zum Jahr 2017 drei von vier Unternehmen zu einer bi-modalen IT-Struktur übergehen werden, das heißt zu einer IT mit zwei Geschwindigkeiten und unterschiedlichen qualitativen Anforderungen: eine, die vorhandene Apps unterstützt, bei denen Stabilität und Zuverlässigkeit gefordert ist, und eine andere, die schnelle IT für Innovationen und geschäftskritische Projekte liefert. Um diese Forderung zu ermöglichen, führen viele Unternehmen Prozesse und Instrumente ein, die kurzlebige virtuelle Maschinen, Container und Mikro-Services den traditionelleren, langlebigen Computer-Plattformen vorziehen.

Diese neuen Tools und Frameworks ermöglichen zwar mehr Geschwindigkeit und Skalierbarkeit, bieten aber keine zentralisierten Sicherheitsmechanismen. Daher wird bei der Sicherheit oft auf die herkömmliche langsame, manuelle und fehleranfällige Arbeitsweise zurückgegriffen. Schlimmer noch, Sicherheitsrichtlinien und -verfahren werden oft ignoriert, anstatt die Aufgabe einfach nur schnell zu erledigen.

Schlüssel und Zertifikate sind die Grundlage der Sicherung moderner SSL/TLS-basierter Datenkommunikationen
Dieses grundlegende System des Vertrauens, auf dem das Internet basiert, ist durch nichts zu ersetzen und wird es in nächster Zeit auch nicht sein - was bedeutet, dass viele Schlüssel und Zertifikate langfristig eingesetzt werden und ihre Zahl beständig steigen wird.

Schnellunterwegs mit Schlüsseln und Zertifikaten
Der Beschaffungsprozess korrekt ausgestellter Zertifikate fällt für DevOps oftmals in die Kategorie der "SlowOps” veralteter IT und verringert die Geschwindigkeit ganz erheblich. DevOps-Teams arbeiten oft außerhalb der Sicherheitsgrenzen, Richtlinien und Grundsätze der Unternehmen. Diese Abschottung trägt dazu bei, dass die Teams Entwicklungen und neue Innovationen schneller fertig bekommen - und zwar in einer Geschwindigkeit, die mit dem Geschäftstempo Schritt hält. Dies bringt aber potentielle Sicherheitsrisiken und schlechte Praktiken in genau den Umgebungen mit sich, die von ihnen erstellt werden - alles zugunsten der Schnelligkeit.

Hier einige Beispiele dafür, was DevOps-Teams tun könnten, um die Zeit, die sie normalerweise für die Beschaffung von Zertifikaten für ihre Umgebungen benötigen, zu verkürzen.

Ein paar Beispiele für abgekürzte Verfahren sind:
• >> Kein TLS/SSL nutzen
• >> Eigene Zertifizierungsstellen errichten
• >> Selbst-unterzeichnende Zertifikate erstellen
• >> Nicht anerkannte Aussteller von Zertifikaten nutzen
• >> Zertifikate mit schwachen Signatur-Algorithmen erstellen
• >> Zertifikate mit langen Ablauffristen erstellen
• >> Sicherheitsrichtlinien falsch interpretieren oder völlig ignorieren

Solche Plattformenkönnen dagegen so konfiguriert werden, dass sie ihre Workflows und Prozesse gezielt ganz oder teilweise über leicht anzuwendende REST APIs exponiert. Diese APIs können dann von fast allen DevOps direkt genutzt werden, mitsamt kontinuierlicher Integration/Lieferung, automatisiertem Aufbau/Bereitstellung und Container-Lösungen, wie "Chef", "Ansible", "Puppet", "SaltStack", "Hashicorp", "Docker", "Kubernetes" oder"UrbanCode", um nur einige zu nennen.

Fazit: Schnelle Sicherheit mit schneller IT
Solche Plattformen ermöglichen es Unternehmen, die Vorteile einer schnellen IT ohne Beeinträchtigung der Sicherheit zu nutzen. Mit der API können Security-Teams Richtlinien jetzt zentral definieren, und so dafür sorgen, dass DevOps den Sicherheitsrichtlinien und Best Practices ordnungsgemäß entsprechen. Sie machen esDevOps-Teams leicht, Sicherheit von Anfang an korrekt anzuwenden und zu integrieren.

Plattformen wie diese bietenDevOp-Teams folgende Vorteile:
• >> Eindeutige Schlüssel und Zertifikate werden auf Verlangen innerhalb von Sekunden erzeugt
• >> Für DevOps wird die gleiche Plattformverwendet wie für bereits vorhandene Sicherheitsteams und Systemadministratoren
• >> Einheitliche Sicht auf die Sicherheitslage und Compliance bei Integration in Help Desk-Systeme und SIM/SIEM-Umgebungen
• >> Automatisierte Problembehebung und Neuanmeldung bei geänderten Standards und Richtlinien
• >> Automatische Warnmeldungen nach erkannten Anomalien innerhalb wie außerhalb einer Organisation
• >> Praktisch grenzenlose Skalierbarkeit ohne zusätzlichen Verwaltungsaufwand
(Venafi: ra)

eingetragen: 29.04.16
Home & Newsletterlauf: 31.05.16


Venafi: Kontakt und Steckbrief

Der Informationsanbieter hat seinen Kontakt leider noch nicht freigeschaltet.

- Anzeigen -





Kostenloser IT SecCity-Newsletter
Ihr IT SecCity-Newsletter hier >>>>>>

- Anzeigen -


Meldungen: Grundlagen

  • Große Zahl ungesicherter IoT-Geräte

    DDoS-Angriffe haben sich in den letzten sechs Monaten nahezu verdoppelt. Laut einer Studie von Corero Network Security entspricht das einem monatlichen Mittel von 237 Angriffsversuchen. Einer der Gründe für den Anstieg liegt in der hohen Zahl einfach zu übernehmenden IoT-Geräten, die zumeist nur unzureichend geschützt sind. Diese "smarten" Geräte eignen sich dann ganz vorzüglich um zu einem Teil eines riesigen Botnets zu werden. Dieses Problem wird sich weiter verschärfen. Dazu muss man nur an die unzähligen Gadgets für Endverbraucher denken, die etwa in der Weihnachtszeit über die physischen und virtuellen Ladentische gewandert sind. Diese Geräte sind eines der vordringlichen Ziele für die Übernahme durch Hacker. Neben den Bedenken, die man im Hinblick auf die Sicherheit der Privatsphäre und vertraulicher Daten hegen kann gibt es noch eine ganze Reihe von weiteren ernsthaften Gefahren, die mit diesen Geräten verbunden sind. Hacker machen sich unsichere IoT-Geräte zunutze um riesige Bot-Netze aufzubauen und DDoS-Attacken zu lancieren. Unsichere IoT-Devices waren in einigen der größten DDoS-Angriffe auf Online-Plattformen innerhalb der letzten Jahre beteiligt. Es spielt bei DDoS-Angriffen keine Rolle, wie groß ein Unternehmen ist. Gefährdet sind alle. Und sollten entsprechend Sorge tragen, was die Sicherheit ihrer Geräte, Daten und Netzwerke anbelangt.

  • A fool with a tool

    Unternehmen stehen heute vielfältige Sicherheitslösungen zur Verfügung. Doch ein Sammelsurium aus technischen Einzelmaßnahmen kann nur bedingt gegen Angriffe schützen. Vielmehr benötigen Unternehmen eine Informationssicherheitsstrategie, gestützt auf Prozesse und Tools die es einem Unternehmen ermöglichen, Informationssicherheit effizient und effektiv zu managen. Der Schlüssel zum Erfolg wird dabei im richtigen Mix aus Menschen und deren Fähigkeiten, Prozessen und Tools liegen. Nur so wird es Unternehmen gelingen proaktiv zu agieren und durch Antizipation zukünftiger Bedrohungen und entsprechender Vorbereitung die richtigen Maßnahmen zum Schutz ihrer sensiblen Daten zu treffen.

  • Was ist Certificate Transparency?

    Möglicherweise haben Sie schon vor einigen Jahren von Certificate Transparency (CT) gehört, als Google die Anforderung für alle Extended Validation (EV) SSL/TLS-Zertifikate ankündigte, die nach dem 1. Januar 2015 ausgestellt worden sind. Seitdem hat Google die Anforderung auf alle Arten von SSL-Zertifikaten ausgedehnt und zuletzt eine Frist bis zum April 2018 gesetzt. Zertifikaten, die nicht CT-qualifiziert sind und die nach diesem Datum ausgestellt werden, wird in Chrome nicht vertraut. GlobalSign hat im Hintergrund bereits daran gearbeitet, dass alle Zertifikate mit CT ausgestattet werden - Extended Validation (EV) seit 2015, Domain Validated (DV) seit August 2016 und Organisation Validated (OV) ab Oktober 2017 - GlobalSign-Kunden sind damit für den Fristablauf seitens Google gerüstet.

  • Wo ist der Authentifizierungsprozess fehlbar?

    Ich habe den größten Teil meines beruflichen Lebens damit verbracht Authentifizierungslösungen zu programmieren, zu implementieren, weiterzuentwickeln und zu patentieren. Daher nehme ich mir das Recht heraus zu sagen, letzten Endes funktioniert Authentifizierung einfach nicht. Mit "funktionieren" im engeren Sinne meine ich, dass es zu 100Prozent garantiert ist, dass es sich tatsächlich um eine vertrauenswürdige Identität handelt, wenn eine Benutzeridentität von einer Authentifizierungslösung an den betreffenden Partner weitergeleitet wird. Und genau das lässt sich nicht garantieren. Es lässt sich belegen, dass und wie der eigentliche Validierungsprozess innerhalb der Authentisierung funktioniert. Das bedeutet, wir verifizieren mathematisch und empirisch, dass die von einem Authentifizierungsmechanismus zusammengestellte Entität mit den Werten übereinstimmt, die in der Datenbank des akzeptierenden Dritten gespeichert sind, also "matched". Das kann ein Passwort sein, ein Einmal-Passwort, OTP, X.509-basierte Verschlüsselung, biometrische Merkmale, mobile Push-Werte oder eine Gesichtserkennung. In einem Satz: Der Authentisierungsprozess lässt sich validieren und damit auch, dass das technische System korrekt arbeitet.

  • Rollende Sicherheitslücken

    Viele Fahrzeuge sind heutzutage längst zu rollenden Computern geworden, denn bereits jetzt stecken in der Software eines modernen Oberklasse-PKW etwa 100 Millionen Codezeilen. Zum Vergleich: Die Flugsoftware einer Boeing 787 Dreamliner kommt mit etwa 14 Millionen Zeilen aus. Die Erwartungen an das zukünftige autonom fahrende Auto sind vielzählig: Mehr Sicherheit auf den Straßen, mehr Komfort, beispielsweise durch selbstständiges Einparken, die Nutzung eines Autopiloten im Stau oder komplett fahrerlose Roboterautos, welche im Car-Sharing-Verfahren neue Infrastrukturmöglichkeiten bieten könnten. Dem gegenüber stehen die Ängste: Bei Technikfehlern nur noch ein hilfloser Passagier an Board zu sein oder Opfer eines Hacker-Angriffs zu werden.