Wie ein IL4-Identity-Anbieter erfolgreich IL5-Umgebungen betreut

Durch die Einführung der Cloud und neuer Standards kann das US-Verteidigungsministerium (DoD) seine Informationssysteme verbessern und die Modernisierung der Cybersicherheit gemäß den Anforderungen von Säule 1 der Nationalen Cybersicherheitsstrategie, Abschnitt 3 der Executive Order (EO) 14028, Verbesserung der Cybersicherheit der Nation, und Abschnitt 1 des National Security Memorandum zur Verbesserung der Cybersicherheit der nationalen Sicherheit, des Verteidigungsministeriums und der nachrichtendienstlichen Community-Systeme (NSM8) vorantreiben. 

Das Ziel des Ministeriums, eine moderne, bedrohungsbasierte Infrastruktur für Soldatinnen und Soldaten zu schaffen, lässt sich jedoch nicht im Alleingang erreichen. Die Kampagne zur Sicherung von Cloud-Services ist eine gemeinsame Verantwortung der im DoD zuständigen Missionsbeauftragten und der Cloud-Service Provider (CSPs). Die Leitlinie der der Behörde für Verteidigungsinformationssysteme (Defense Information Systems Agency, DISA) zu den Anforderungen an die Sicherheit von Cloud Computing (Cloud Computing Security Requirements Guide, CC SRG) bietet neben der Leitlinie an sich ein Framework für die Implementierung kommerziell verfügbarer Cloud Computing-Dienste.

Auswirkungsgrade, so genannte Impact Levels (IL), bilden die Grundlage dieses Frameworks. Jedes Impact Level entspricht einer bestimmten Vertraulichkeits- und Risikostufe sowie einer Teilmenge der Sicherheitskontrollen gemäß Committee on National Security Systems Instruction (CNSSI) Nr. 1253. Die ILs schreiben auch Konnektivitätsanforderungen vor, von denen einige Cloud Access Points (CAPs) umfassen. Über CAPs können sich Cloud-Angebote über eine DISA- oder Sicherheitstechnologie mit dem NIPRNet verbinden. DISA hat einen Risk Management Framework (RMF)-Prozess für die Bewertung und Autorisierung von Cloud Service Offerings (CSOs) erstellt, der speziell auf das DoD zugeschnitten ist und parallel zum Federal Risk and Authorization Management Program (FedRAMP) existiert.

Auf welcher Ebene CSOs agieren müssen, lässt sich ganz einfach feststellen, indem man die Mission und die Daten, die sie verarbeiten, genauer betrachtet. Hier sind einige Beispiele:
 

Oktas Weg in das Verteidigungsministerium

Im vergangenen Jahr hat Okta intensiv mit DISA zusammengearbeitet, um unser Identity-as-a-Service (IDaaS)-Angebot – in einer exklusiven Umgebung ohne Genehmigungsbeschränkungen für Pilotprogramme – auf das DoD und seine Kooperationspartnerauszudehnen. Diese Bemühungen gipfelten schließlich in einer neuen, bedingten, vorläufigen Genehmigung (Provisional Authorization, PA) für Okta for US Military. Ein Bestandteil dieses Meilensteins ist die Anerkennung der IDaaS-Lösung von Okta durch den Authorizing Official (AO) der DISA als Identity and Access Management (IAM)-Service für IL5-Umgebungen.

Wie kann ein IL4-IDaaS für das Zugriffsmanagement in einem IL5-System verwendet werden? Um diese Frage zu beantworten, müssen wir noch einmal auf die Kontrollen und Daten zu sprechen kommen.

Beginnen wir mit den Daten. IDaaS ist eine Cloud-basierte Identity and Access Management (IAM)-Plattform, die einen zentralen Verwaltungspunkt für den Zugriff auf andere Systeme und Anwendungen bereitstellt, aber Daten nicht im herkömmlichen Sinn „verarbeitet“. Welche Art von Daten würden Sie in einem Benutzerverzeichnis speichern wollen? Daten zur nationalen Sicherheit, sensible personenbezogene Daten oder geschützte Gesundheitsdaten würde man wohl kaum als Account-Attribut speichern wollen. Einer der Grundsätze des Zero-Trust-Modells ist die Annahme, dass sich Angreifende bereits Zugriff auf Ihre Umgebung verschafft haben. Das Platzieren geschützter Informationen in einem Account würde die Arbeit der Akteure erleichtern! Wenn wir IDaaS als unterstützende Funktion für ein Gesamtsystem (oder eine Familie von Systemen) betrachten, leuchtet ein, dass geschützte Daten nicht in einem Directory gespeichert werden sollten. Wenn Sie etwa eine eindeutige Kennung für Ihre Mitarbeitenden benötigen, verwenden Sie besser deren Electronic Data Interchange Personnel Identifier (EDIPI) und nicht die Sozialversicherungsnummer.

Der zweite Faktor ist das Modell der Vererbung von Kontrollen. IDaaS bietet vererbbare Kontrollen basierend auf seiner Eigenschaft als Teil einer übergreifenden Systemarchitektur. Der Okta System Security Plan (SSP) und die vererbbaren Kontrollen werden zu einer unschätzbaren Referenz für alle, die ein Vererbungsmodell entwerfen. Da IDaaS keine CUI-Daten speichert, muss der Großteil der zusätzlichen Kontrollen mit IL5 in den Systemen eingesetzt werden, in denen die CUI-Daten gespeichert sind. Mit Okta können diese zusätzlichen Anforderungen im Rahmen eines hybriden Ansatzes einfacher erfüllt werden. Vor diesem Hintergrund sind nur die Kontrollen, die Okta direkt beeinflusst, als vererbbar gekennzeichnet. So bietet Okta zum Beispiel FIPS 140-2-Verschlüsselung für die gespeicherten Daten, nicht aber für die Daten in Ihrem Wartungssystem für die Kriegsführung.

Der letzte Faktor sind die zusätzlichen Investitionen von Okta in das Hosting der Umgebung auf einer .mil-Domain und die Einschränkung der Nutzung auf vom DoD genehmigte Entitäten. Dies ist ein wichtiger Schritt bei unserem fortlaufenden Engagement für das DoD. Diese architektonischen Komponenten (Daten, Kontrollen und Exklusivität) sind die logischen Faktoren, die es der DISA ermöglichten, Okta for US Military eine bedingte PA der Stufe IL4 zu gewähren und die Verwendung von IDaaS zur Unterstützung von IL5-Umgebungen zu gestatten. Diese einzigartige Situation verdeutlicht die Zukunft von Okta als führendes Unternehmen bei der DoD-Cloud-Migration und den Zero-Trust-Bemühungen.

Wenn Sie mehr über diese Bemühungen und die IL5-Anwendungen erfahren möchten, in die Okta integrierbar ist, laden Sie unser Whitepaper über die Bereitstellung von modernem Identity-Management für die nationale Sicherheit herunter oder kontaktieren Sie uns unter federal@okta.com.