Dies ist der erste Blogbeitrag einer dreiteiligen Serie über die Rolle der Identität in CMMC 2.0.
BLUF: Eine entscheidende Frage, die jeder Zugriffsrichtlinie zugrunde liegt: Sind Sie wirklich die Person, für die Sie sich ausgeben?
Dieser Beitrag befasst sich eingehend mit der Kontrollfamilie Identifizierung und Authentifizierung (IA). Wir zeigen, warum eine starke Identitätsverifizierung die zwingende Voraussetzung für eine sicherere Zugriffskontrolle ist, und demonstrieren, wie Okta dabei hilft, diese Anforderungen auf jeder Reifegradstufe von CMMC 2.0 zu erfüllen.
Ein Überblick: Authentifizierung ist die Grundlage der Zugriffskontrolle
Die Kontrollfamilie Identifikation und Authentifizierung (IA) ist der digitale Wächter für Ihre Organisation. Sein Zweck besteht darin, sicherzustellen, dass jeder Benutzer, jedes Gerät oder jeder Prozess legitim und verifiziert ist, bevor überhaupt versucht werden kann, auf eine Ressource zuzugreifen. Ihre sorgfältig ausgearbeiteten Richtlinien zur Zugriffskontrolle (AC) sind wertlos, wenn die Gewissheit über die Identität, die die Anfrage stellt, fehlt.
Aus diesem Grund legt die Bewertungsmethodik von CMMC 2.0 einen so starken Fokus auf die IA-Kontrollen. Ein Prüfer benötigt Gewissheit und einen Nachweis über die Identität, bevor er den von Ihnen eingeführten Sicherheitsmaßnahmen vertrauen kann.
Mit Okta können Organisationen einen erheblichen Teil dieser hochwertigen Anforderungen sofort erfüllen. Allein in der IA-Familie hilft Ihnen Okta dabei, drei Kontrollen im Wert von 5 Punktenzu erfüllen – die „großen Brocken“, die für das Bestehen Ihres Audits unerlässlich sind.
Lassen Sie uns eine zentrale IA-Kontrolle auf jeder CMMC-Stufe betrachten.
CMMC Level 1: Die grundlegende Ebene
Level 1 konzentriert sich auf „grundlegende Cyberhygiene“ und ist für Auftragnehmer:innen erforderlich, die Federal Contract Information (FCI) verarbeiten. Es stellt sicher, dass Sie über die wesentlichen Grundlagen verfügen.
Zentrale Level-1-Kontrolle: IA.L1-3.5.1
CMMC-Anforderung | NIST SP 800-53 korrelierte Kontrolle |
|---|---|
IA.L1-3.5.1: Benutzer:innen, Prozesse oder Geräte von Informationssystemen identifizieren und authentifizieren. | IA-2: Identifizierung und Authentifizierung (Organisationsbenutzer:innen): Das Informationssystem identifiziert und authentifiziert Organisationsbenutzer:innen (oder Prozesse, die im Namen von Organisationsbenutzer:innen handeln) eindeutig. |
Diese Kontrolle erfordert, allen Benutzer:innen eine eindeutige Identität zuzuweisen und gemeinsam genutzte Accounts zu eliminieren.
Wie Okta die Kontrolle erfüllt:
Das Okta Universal Directory und Single Sign-On (SSO) sind die perfekten Tools für diese CMMC-Anforderung. Okta fungiert als zentrale Informationsquelle für alle Benutzeridentitäten und stellt sicher, dass jede Person genau ein Konto hat. Indem Sie Ihre Anwendungen mit Okta SSO föderieren, stellen Sie sicher, dass diese einzige, eindeutige Identität für jede Anmeldung verwendet wird, sodass gemeinsam genutzte Konten der Vergangenheit angehören.
- Praxisszenario: Ein kleiner DIB-Zulieferer meldet sich im Portal eines Hauptauftragnehmers an, um auf FCI wie Lieferpläne zuzugreifen. Anstatt einen gemeinsamen shipping@supplier.com -Account zu verwenden, nutzt das Unternehmen Okta, um jedem Mitarbeitenden einen eindeutigen Benutzeraccount zuzuweisen. Wenn ein Mitarbeiter auf das Portal zugreift, authentifiziert er sich mit seinen persönlichen Anmeldedaten bei Okta, wodurch sichergestellt wird, dass jede Aktion direkt mit ihm verknüpft ist und die für Level 1 erforderliche grundlegende Nachvollziehbarkeit erfüllt wird.
IA.L1-3.5.1 Designempfehlungen:
Um diese Kontrolle zu implementieren, konfigurieren Sie Okta als Ihren zentralen Identity Provider, indem Sie es mit einer Quelle der Wahrheit, wie Ihrem HR-System, verbinden oder Benutzerprofile direkt im Okta Universal Directory erstellen. Konfigurieren Sie für jede Ihrer Anwendungen eine SSO-Integration mit SAML oder OIDC. Stellen Sie unbedingt sicher, dass die Anwendung so konfiguriert ist, dass Anmeldungen nur über Okta zulässig sind, und deaktivieren Sie die Möglichkeit für Benutzer, separate lokale Accounts mit Benutzernamen und Passwort zu erstellen. Dies erzwingt die Nutzung der einzigen, verwalteten Identität für alle Zugriffe.
IA.L1-3.5.1 Compliance-Nachweis:
Um einer Prüferin oder einem Prüfer die Compliance nachzuweisen, würden Sie Ihr Okta Universal Directory vorlegen, um zu belegen, dass jede Mitarbeiterin und jeder Mitarbeiter über ein eindeutiges Benutzerprofil verfügt. Dann würden Sie zur Konfigurationsseite einer wichtigen Anwendung (z. B. Microsoft 365) navigieren und die SSO-Einstellungen anzeigen, wobei Sie darauf hinweisen, dass diese mit Okta föderiert ist. Schließlich würden Sie das Okta System Log aufrufen, nach der letzten Anmeldung einer bestimmten Benutzerin oder eines bestimmten Benutzers filtern und das detaillierte Event-Protokoll anzeigen, um zu beweisen, dass jede Aktion auf eine eindeutige actor.id zurückzuführen ist.
CMMC Level 2: Der CUI-Gatekeeper
Stufe 2 richtet sich an Auftragnehmer:innen, die sensiblere Controlled Unclassified Information (CUI) verarbeiten. Diese Stufe ist auf NIST SP 800-171 abgestimmt und erfordert eine wesentlich robustere Sicherheit.
Zentrale Level-2-Kontrolle: IA.L2-3.5.3
CMMC-Anforderung | NIST SP 800-53 korrelierte Kontrolle |
|---|---|
IA.L2-3.5.3: Verwenden Sie die Multi-Faktor-Authentifizierung für den lokalen und den Netzwerkzugriff. | IA-2(1): Netzwerkzugriff auf privilegierte und nicht privilegierte Konten: Das Informationssystem implementiert Multi-Faktor-Authentifizierung für den Netzwerkzugriff auf privilegierte und nicht privilegierte Konten. |
Diese 5-Punkte-„Big Rock“-Maßnahme schreibt vor, dass ein Passwort allein nicht ausreicht. Müssen Sie einen zweiten Authentifizierungsfaktor (MFA) erzwingen, um sich vor Passwortdiebstahl zu schützen.
Wie Okta die Kontrolle erfüllt:
Okta Adaptive MFA ist das perfekte Tool für diese CMMC-Anforderung. Als zentraler Identitätsanbieter kann Okta für jeden Zugriffsversuch auf jede Anwendung, die CUI verarbeitet, eine starke MFA erzwingen. Richtlinien können so konfiguriert werden, dass sie MFA für alle Benutzer erfordern und sich je nach Risiko anpassen, indem beispielsweise ein stärkerer Faktor verlangt wird, wenn sich ein Benutzer über ein nicht vertrauenswürdiges Netzwerk verbindet.
- Praxisbeispiel: Ein Luft- und Raumfahrtingenieur im Homeoffice benötigt Zugriff auf eine Cloudbasierte CAD-Anwendung, die CUI enthält. Um sich anzumelden, geben sie zuerst ihr Passwort ein. Okta fordert sie dann auf, eine Push-Benachrichtigung auf ihrem registrierten Smartphone zu bestätigen. Erst nachdem sie diesen zweiten Faktor bestätigt haben, erhalten sie Zugriff auf die sensiblen Design-Dateien. Ein Angreifer, der ihr Passwort durch Phishing erbeutet hat, würde bei der MFA-Herausforderung sofort gestoppt werden.
IA.L2-3.5.3 Design-Empfehlungen:
Erstellen Sie in Ihrer Okta-Administratorkonsole eine Richtlinie für die „ Authentifikator-Registrierung “, die vorschreibt, dass alle Nutzer mindestens einen MFA-Faktor registrieren. Erstellen Sie dann eine „ Sign-On-Richtlinie “ und wenden Sie diese auf alle Anwendungen an, die CUI verarbeiten. Konfigurieren Sie die Regeln in dieser Richtlinie so, dass sie für jede Anmeldung eine „Multifaktor-Authentifizierung erfordern“. Eine Best Practice besteht darin, die Regel festzulegen, dass ein Benutzer in einem nicht vertrauenswürdigen Netzwerk immer zur MFA aufgefordert wird. Fordern Sie für eine noch stärkere Sicherheitslage einen phishing-resistenten Faktor für jeden Zugriff auf diese kritischen Apps.
IA.L2-3.5.3 Compliance-Nachweis:
Für einen Prüfer würden Sie zunächst die von Ihnen erstellte Anmelderichtlinie anzeigen, aus der die Regel hervorgeht, die bei jeder Anmeldung an einer CUI-führenden Anwendung die Multi-Faktor-Authentifizierung (MFA) explizit erzwingt. Sie würden dann eine Live-Demonstration durchführen: Sie versuchen, sich als Testbenutzer:in bei dieser Anwendung anzumelden, und zeigen der Prüfer:in die Live-MFA-Aufforderung, die auf einem registrierten Gerät erscheint. Zeigen Sie ihnen abschließend das entsprechende Erfolgs-Event der „ Multifaktor-Authentifizierung “ für diese:n Benutzer:in im Okta System Log.
CMMC Level 3: Die Expertenverteidigung
Level 3 ist für Organisationen in den Programmen des DoW mit der höchsten Priorität vorgesehen. Es erfordert alle L2-Kontrollen sowie erweiterte Kontrollen aus NIST SP 800-172 zum Schutz vor Advanced Persistent Threats (APTs).
Zentrale Level-3-Kontrolle: IA.L3-3.5.4e
CMMC-Anforderung | NIST SP 800-53 korrelierte Kontrolle |
|---|---|
IA.L3-3.5.4e: Setzen Sie eine phishing-resistente Authentisierung mit Multifaktorverfahren für alle privilegierten und nicht privilegierten Zugriffe ein. | IA-2(8): phishing-resistent / replay-resistent: Das Informationssystem verwendet Authentifizierungsmechanismen, die phishing-resistent und replay-resistent sind. |
Diese erweiterte Kontrolle schreibt die Verwendung von Phishing-resistenter MFA vor, um komplexe Angriffe abzuwehren, die schwächere MFA-Typen umgehen können.
Wie Okta die Kontrolle erfüllt:
Okta verfügt über einige der branchenweit stärksten phishing-resistenten Authentifikatoren, die diese CMMC-Anforderung auf Expertenebene erfüllen. Dazu gehören FIDO2/WebAuthn-konforme Hardware-Sicherheitsschlüssel wie YubiKeys und passwortlose Lösungen wie Okta FastPass, die Plattform-Biometrie wie Windows Hello oder Apples Face ID/Touch ID nutzen. Die Richtlinien von Okta können so konfiguriert werden, dass sie für alle Benutzer, die auf die hochwertige CUI-Umgebung zugreifen, ausschließlich diese phishingresistenten Faktoren erfordern.
- Praxisbeispiel: Ein IT-Sicherheitsanalyst bei einem führenden Rüstungsunternehmen verwaltet Systeme, die hochsensible kontrollierte, nicht klassifizierte Informationen (CUI) enthalten. Um auf die Administratorkonsole zuzugreifen, müssen sie sich über Okta authentifizieren. Nach Eingabe ihres Passworts werden sie aufgefordert, den in ihre Workstation eingesteckten YubiKey zu berühren. Der Schlüssel führt ein kryptografisches Challenge-Response-Verfahren durch, das für sie und den Okta-Service einzigartig ist. Dies beweist ihre Identität mit dem höchsten Maß an Sicherheit und macht es für raffinierte Angreifer unmöglich, ihre Anmeldedaten abzufangen.
IA.L3-3.5.4e Design-Empfehlungen:
Stellen Sie in Ihrer Okta-Richtlinie „Authentifikator-Registrierung“ sicher, dass FIDO2/WebAuthn-Authentifikatoren aktiviert sind. Erstellen oder bearbeiten Sie dann Ihre Sign-On-Richtlinie für CUI-Anwendungen. Erstellen Sie anstelle einer allgemeinen MFA-Anforderung eine Regel, die explizit einen Authentifikator mit „Phishing-Resistenz“ als erforderliche Eigenschaft verlangt. Diese Regel erzwingt die Verwendung von Faktoren wie einem YubiKey oder Okta FastPass, die die integrierte Biometrie eines Geräts nutzen, und lässt keine schwächeren Faktoren wie SMS oder Sicherheitsfragen für den Zugriff auf diese hochsensiblen Anwendungen zu.
IA.L3-3.5.4e Compliance Nachweis:
Um dies einem Prüfer oder einer Prüferin zu demonstrieren, zeigen Sie die von Ihnen konfigurierte Regel der Anmelderichtlinie, die speziell phishing-resistente Authentifikatoren erfordert. Führen Sie dann eine Live-Demonstration der Anmeldung durch. Versuchen Sie zunächst, sich mit einem nicht phishingresistenten Faktor (wie einer Push-Benachrichtigung) anzumelden; zeigen Sie anschließend, dass der Zugriff verweigert wird. Wiederholen Sie dann die Anmeldung mit einem YubiKey oder Okta FastPass mit Windows Hello und überprüfen Sie, ob der Zugriff erfolgreich gewährt wird. Dies liefert einen unwiderlegbaren Nachweis der Durchsetzung.
Setzen Sie Ihre CMMC-Reise auf einem soliden Fundament fort
Durch die Kombination einer starken Zugriffskontrolle mit einer resilienten Identifizierung und Authentifizierung schaffen Sie eine robuste Abwehr für Ihre CUI und ein solides Fundament für Ihr CMMC-Audit. Die Zentralisierung Ihrer Strategie auf einer modernen Identitäts-Plattform stellt sicher, dass die richtigen Personen – und nur die richtigen Personen – Zugriff auf die richtigen Ressourcen erhalten.
Freuen Sie sich auf unseren nächsten Beitrag in dieser Reihe, in dem wir näher auf die Domain Audit und Rechenschaftspflicht (AU) eingehen, um zu zeigen, wie Sie nachweisen können, dass Ihre Sicherheitskontrollen wie vorgesehen funktionieren.
Um mehr darüber zu erfahren, wie Okta Ihrem Unternehmen helfen kann, die CMMC-Anforderungen zu erfüllen, laden Sie unseren CMMC-Erkennungsleitfaden unter https://www.okta.com/resources/datasheet-okta-cmmc-discovery-guide/ herunter Oder kontaktieren Sie uns unter okta.com/contact-sales/.
Obwohl dieser Artikel bestimmte rechtliche Konzepte behandelt, stellt er keine Rechtsberatung dar und sollte nicht als solche ausgelegt werden. Dies dient ausschließlich Informationszwecken. Für eine Rechtsberatung bezüglich der Compliance-Anforderungen an Ihr Unternehmen, wenden Sie sich bitte an die Rechtsabteilung Ihres Unternehmens. Okta macht keinerlei Zusicherungen, übernimmt keinerlei Gewährleistung oder keinerlei sonstigen Garantien für den Inhalt dieses Artikels. Informationen zu den vertraglichen Zusicherungen von Okta gegenüber Kunden finden Sie unter okta.com/agreements.
