Authentifizierung als Service beziehen

Der Unterhalt eigener Systeme für die Authentifizierung verursacht Kosten und benötigt Expertise, die unter Umständen schwer zu bekommen ist. Immer mehr Organisationen setzen also auf Cloud Dienste, die die Authentifizierung für sie übernehmen. Der Markt für Authentication as a Service (AaaS) wächst stark und entsprechend gibt es viele verschiedene Produkte, wie beispielsweise Microsoft Azure AD oder das Google Identity Management.

Ich gehe an dieser Stelle auf die Eigenschaften von SaaS-Angeboten ein und nenne Kriterien, anhand deren sich die Sicherheit und Eignung einer Lösungen beurteilen lässt. Ziel ist die Identifikation der derjenigen Punkte, die bei einer Entscheidung aus Sicht der Architektur und des Geschäfts berücksichtigt werden müssen.

Viele Firmen sind heute, was die Identifizierung von Mitarbeitern angeht, eine Zweiklassengesellschaft: Mitarbeiter mit und Mitarbeiter ohne Accounts. Da Prozesse wie etwa Personalprozesse zunehmend digitalisiert werden, steigt hier der Bedarf an digitaler Identifizierung. Vor einer Anschaffung einer solchen Software oder der Transformation in einen Cloud Service müssen diverse Überlegungen angestellt werden, um die richtige Lösung für eine Organisation zu finden.

Generell lassen sich von AaaS die gleichen kritischen Anmerkungen wie bei anderen Cloud-Lösungen anbringen. In vielen Fällen kommt bei Firmen heute bereits ein Dienstleister für die Authentifizierung zum Einsatz, beispielsweise wenn SMS Token verwendet werden, sodass der Einbezug eines Dienstleisters nicht kategorisch ausgeschlossen werden sollte. Denn es ist auch möglich einen DDoS-Angriff auf einen SMS Provider vorzunehmen. Wichtig ist, dass man sich bewusst ist, was man dem Service Provider anvertraut und wie weit dieses dann Risiken für das eigene Geschäft nach sich zieht. Es lohnt sich deswegen die folgenden Kriterien abzuklären:

Anforderungen an die Verfügbarkeit: Bei der Verwendung von AaaS ist zu beachten, dass der Service mindestens das selbe Service-Level erfüllt, wie die Services, welche damit bedient werden sollen. Wird der Service über das Internet bezogen, so ist es möglich, dass der Provider des Dienstes einem DDoS-Angriff ausgesetzt wird. Wird die AaaS nur von Webapplikationen verwendet, welche lediglich über das Internet verfügbar sind, sind diese über einen DDOS-Angriff auch angreifbar. Fakt bleibt aber, dass ich beim Einsatz von AaaS nur noch den Authentication Provider angreifen muss, um alle meine Applikationen lahmzulegen. Es lohnt sich hier die Maßnahmen des Service Providers hinsichtlich solcher Szenarien zu prüfen. Wird der Service auch für interne Applikationen eingesetzt, wird dies meist über interne Komponenten (z.B. MFA Server) abgewickelt. Die Kommunikation zum Service Provider wird in diesen Fällen meist nicht über das Internet, sondern über eine Mietleitung erfolgen.

Anforderungen an die Performance: Wichtig ist hier, dass die Performance den Anforderungen entspricht und eine maximale Skalierung für die eigenen Bedürfnisse geprüft wird. Das bedeutet, dass der Anbieter ausreichend Kapazität für eine bestimmte Latenz bei einer maximalen Anzahl von Authentifizierungen pro Sekunde sicher stellt. Die Auslieferung von Token über SMS kann je nach Land etwas dauern. Bei eigenen Websystemen kann man dem Rechnung tragen (Authentication Timeout). Bei eingekauften Services, z. B. VPN Client, oder SaaS-Applikationen muss hier der Anbieter der Software im zweifelsfalle notwendige Anpassungen vornehmen. Diese Punkte sollten vor der Beschaffung eines Authentifizierungs Service geprüft und auch getestet werden.

Anforderung an die Vertraulichkeit: Die Anforderungen an die Vertraulichkeit der technischen Lösungen unterscheiden sich nicht, egal ob diese intern bereitgestellt oder als Service bezogen wird. Bei der Bereitstellung von AaaS ist aber zu beachten, wie diese genau erfolgt. Da ein Serviceanbieter viele Kunden hat, ist genau zu beachten, wie die Trennung der Mandanten erfolgt. Erfolgte Zertifizierungen helfen diese Bewertung vorzunehmen.

Anforderung an die Nachweisbarkeit: Wichtig ist bei einem Bezug eines Services, dass eine lückenlose Nachweisbarkeit (oder Nichtabstreitbarkeit, engl. Nonrepudiation)  der Authentifizierungsvorgänge und der Konfigurationen vorliegen.

Vertragliche Aspekte: Setzt man eine Authentication Provider beispielsweise für die Authentifizierung von Cloud (SaaS) Applikationen eines weiteren Providers ein, kann eine Dreiecksbeziehung bestehen. Diese muss vertraglich sauber definiert werden, damit im Falle eines Falles beispielsweise geklärt ist, wer auf die Logs zugreifen darf. Es könnte ja sein, dass eingebrochen wird und dies wird durch den SaaS-Anbieter untersucht. Dann muss er eben auf die Daten des Authentication Providers zugreifen dürfen.

Datenschutz und Rechtliche Aspekte: Generell braucht der Service Provider minimale Angaben um eine Authentifizierung durchführen zu können. Im Minimum handelt es sich dabei um eine Verbindung des  Geräts (bzw. Telefonnummer oder E-Mail Adresse), das für die Authentifizierung eingesetzt wird (2FA) und dem Benutzer, für den eine Authentifizierung durchgeführt werden soll. Wird der Benutzer für diesen Vorgang anonymisiert, bestehen keine datenschutzrechtlichen Bedenken. Sofern es sich bei der Telefonnummer um eine private Telefonnummer handelt, möchte der Benutzer meistens nicht, dass außer dem Authentifizierungsservice diese Nummer weiter bekannt gemacht wird. Dem ist Rechnung zu tragen, ansonsten kann die Akzeptanz des Services darunter leiden. Mehr Informationen zum Datenschutz findest Du im letzten Blogeintrag.

DevOps: Die AaaS sollte sich gut in die Systemlandschaft integrieren lassen. Hierfür sind APIs für die Automatisierbarkeit der Identifizierungsprozesse ebenso notwendig wie die Möglichkeit der Einbindung in das eigene Monitoring.

Vertrauen gegen Risiko: Die meisten Benutzer benötigen keinen Zugang zu Daten und Dokumenten mit hoher Vertraulichkeit, andere aber teilweise schon. Da Sicherheit und Bedienbarkeit einander behindern, ist es sinnvoll, nicht das selbe Zugangsverfahren bei jeder Gelegenheit zu verwenden, sondern Abhängig von Sicherheitsklassifikation, Zeit, Lokation, Gerät und Benutzer eine andere Methode einzusetzen. Man nennt das auch Risiko-basierte Authentifizierung oder Kontext-basierte Logins.

Kosten: Für den Vergleich der Kosten bei einem Bezug eines Cloud Services sollten Eins-zu-eins-Vergleiche erstellt werden. So lässt sich herausfinden, ob das Kostenmodell des Providers günstiger sein wird als der Eigenbetrieb.

Usability: Eine Bewertung der Usability gegen die Anforderungen der Benutzer sollte durchgeführt werden. Hierbei sollte man auch auf die Usability für den Service Desk achten.

Prozesse: Wie werden die Prozesse der Identifizierung mit der neuen AaaS-Lösung funktionieren? Reicht auch hier die Usability aus?

Architektur: Ist nur On Premise oder nur Off Premise möglich, oder gibt es auch eine gemischte Variante?

Ich hoffe diese Liste von Kriterien ist dem Leser eine Hilfe bei der Auswahl des richtigen Providers.

Kommentar verfassen