Seit jeher mussten sich IT- und Sicherheitsteams von Behörden zwischen flexibler, moderner Cloud-Automatisierung und starren, Legacy-kryptografischen Sicherheits-Frameworks entscheiden. Jetzt müssen Sie das nicht mehr.
Während US-Regierungsbehörden durch den Einsatz von Tools wie Smartcards und Okta FastPass große Fortschritte bei der Absicherung der menschlichen Authentifizierung erzielt haben, bleibt die Sicherung der Machine-to-Machine-Kommunikation (M2M) im Hintergrund eine zentrale Herausforderung. Wenn Behörden automatisierte Pipelines aufbauen, um die Lebenszyklen von Benutzer:innen zu verwalten, Ressourcen bereitzustellen und Sicherheitsabläufe zu orchestrieren, müssen diese automatisierten Workflows mit externer Infrastruktur interagieren.
In der Vergangenheit bedeutete der Schutz dieser ausgehenden API-Verbindungen oft den mühsamen Umgang mit Shared Secrets, API-Schlüsseln oder der Standardauthentifizierung – Methoden, die ein erhebliches Sicherheitsrisiko bergen, wenn auch nur ein einziges Token offengelegt wird. Um modernen Angreifer:innen einen Schritt voraus zu bleiben, muss ein dynamisches Zero Trust -Sicherheitsmodell über die Login-Box hinaus direkt auf automatisierte Abläufe ausgeweitet werden.
Deshalb freuen wir uns, bekannt zu geben, dass Okta Workflows jetzt ausgehendes Mutual TLS (mTLS) unterstützt. Diese Funktion ist exklusiv auf Organisationen zugeschnitten, die innerhalb unserer Compliance-Zellen agieren, und bietet Teams im öffentlichen Sektor einen hochsicheren, Certificate-based Authentifizierungsmechanismus, der für die strengen Anforderungen stark regulierter Umgebungen entwickelt wurde.
Warum mTLS für Okta Workflows?
Durch die Sicherung der ausgehenden Integrations-Ebene mittels kryptografischer Handshakes – bei denen beide Seiten einer Netzwerkverbindung ihre digitalen Identitäten verifizieren – mindert mTLS die mit gemeinsam genutzten Token verbundenen Schwachstellen.
Mit dem ausgehenden mTLS von Okta Workflows können Bundesbehörden und ihre Partner:
- Beseitigen Sie Secret-Fatigue: Verabschieden Sie sich von statischen API-Token, langlebigen Schlüsseln und der Standardauthentifizierung und ersetzen Sie diese durch eine rotationsfreundliche, kryptografisch gestützte Identitätsprüfung.
- Verbinden Sie moderne Automatisierung mit Legacy-Infrastruktur: Lösen Sie sicher automatisierte Workflows aus, die sich nahtlos mit älteren, stark isolierten externen Systemen verbinden, welche möglicherweise keine modernen Protokolle wie OAuth unterstützen, aber strikt eine Certificate-based gegenseitige Authentifizierung erfordern.
- Setzen Sie Zero Trust für nicht-menschliche Identitäten durch: Erweitern Sie die Prinzipien der Zero Trust Architecture (ZTA) auf automatisierte Workflows, indem Sie die explizite kryptografische Identität der Workflow-Engine überprüfen, bevor externe Aktionen ausgeführt werden.
So funktioniert es: Der Workflows-Trust-Store
Im Mittelpunkt dieser Funktion stehen der Workflows-API-Konnektor und der Trust Store, eine sichere Verwaltungsebene, die nativ in Ihre Compliance-Umgebung von Okta Workflows integriert ist. Der API-Konnektor und der Trust Store fungieren als Ihre zentrale Bibliothek für die API-Verbindungen und Zertifikate, die erforderlich sind, um sichere ausgehende Verbindungen zu initiieren.
Die Einrichtung einer ausgehenden mTLS-Pipeline ist darauf ausgelegt, Vertrauen und Sicherheit streng auf spezifische Verbindungen zu beschränken:
- Hochladen eines Zertifikats einer Zertifizierungsstelle (CA): Administrator:innen laden die erforderlichen CA-Zertifikate direkt in den Workflows-Trust-Store hoch, sodass Okta Workflows die Identität des externen Zieldienstes eindeutig überprüfen kann.
- Konfigurieren Sie den API-Konnektor: Beim Erstellen oder Aktualisieren eines Automatisierungsablaufs navigieren Administrator:innen einfach zum API-Konnektor, wählen mTLS als Authentifizierungstyp aus und verknüpfen ihn mit dem hochgeladenen Zertifikat.
Nach der Bereitstellung löst jede vom Workflow ausgeführte ausgehende Aktion einen gegenseitigen kryptografischen Handshake aus, der beide Seiten der Brücke validiert, bevor auch nur ein einziges Byte an Behördendaten ausgetauscht wird.
Verantwortlichkeiten der Kund:innen und Bundesvorgaben
Die Implementierung eines Defense-in-Depth-Sicherheitsmodells ist ein gemeinsamer Weg. Während Okta eine sichere Umgebung für die Erstellung dieser Automatisierungen innerhalb unserer föderalen Grenzen bereitstellt, tragen Kund:innen weiterhin verschiedene Verantwortlichkeiten, um die Einhaltung staatlicher Vorgaben wie OMB M-22-09 und NIST SP 800-53rev5 zu gewährleisten:
- Endpoint-Konfiguration: Kund:innen sollten sicherstellen, dass ihre empfangende externe Infrastruktur explizit so konfiguriert ist, dass sie mTLS-Zertifikate und deren Aussteller voraussetzt und ordnungsgemäß validiert.
- FIPS-Verschlüsselung: Gemäß den bundesstaatlichen Vorgaben sollten Behörden überprüfen, dass die generierten und verwendeten kryptografischen Module und Zertifizierungsstellen den FIPS-140-Standards entsprechen.
- Lebenszyklusmanagement von Zertifikaten: Behörden sind dafür verantwortlich, Zertifikate, die im Trust Store von Workflows gepflegt werden, gemäß ihren internen Aufgaben und Sicherheitsanforderungen zu verwalten, zu prüfen und zu rotieren.
Sind Sie bereit, die automatisierten Pipelines Ihrer Behörde zu sichern?
Die Sicherung nicht-menschlicher Identitäten und automatisierter Infrastruktur kann komplex sein. Unsere Okta Workflows mTLS-Dokumentation kann Ihrer Behörde den Einstieg in die Konfiguration automatisierter mTLS-Pipelines erleichtern.
Erfahren Sie aus erster Hand, wie Okta den Kampf gegen Identitätsangriffe über menschliche und nicht-menschliche Vektoren hinweg fortsetzt. Wenden Sie sich an Ihre:n Okta-Ansprechpartner:in oder sehen Sie sich unsere Gov Identity Summit On-Demand-Sitzungen an, um zu erfahren, wie Okta Zero Trust in der gesamten Bundesverwaltung ausweitet.
