In diesem Artikel sprechen wir über ein System zur sicheren Durchführung von Authentifizierung und Autorisierung. Lassen Sie uns zunächst verstehen, was der Unterschied zwischen Authentifizierung und Autorisierung ist. Bei handelt es sich um den Vorgang, beim Zugriff auf eine Anwendung nachzuweisen, dass Sie die Person sind, die Sie vorgeben zu sein. der Authentifizierung handelt es sich um den Vorgang, Zugriffsrichtlinien zu definieren und durchzusetzen – also darum, was Sie tun können, sobald Sie authentifiziert sind. Bei der Autorisierung In diesem Artikel werden wir sehen: Warum Authentifizierung und Autorisierung wichtig sind So funktioniert die Authentifizierung So funktioniert die Autorisierung Entwurf eines Authentifizierungssystems Abschluss Warum sind Authentifizierung und Autorisierung wichtig? Nehmen wir an, wir befinden uns in einer Besprechung und Sie leiten das Gespräch. Um die richtige Person nach Updates/dem Status zu fragen, müssen Sie die Person identifizieren (d. h. ). Selbst um vertrauliche Daten mit einer Person zu teilen, müssen Sie die Person korrekt authentifizieren. Und hier kommt die Authentifizierung ins Spiel. authentifizieren Nehmen wir nun an, in derselben Besprechung müssen einige Entscheidungen getroffen werden. Dafür sollten die Personen, die das Recht haben, diese Entscheidungen zu treffen, die Entscheidung treffen. Wir können nicht jedem erlauben, alles zu tun. Offensichtlich sind manche Personen nicht in der Lage, bestimmte Entscheidungen zu treffen, und manche werden mit Sicherheit versuchen, das Schlimmste daraus zu machen. Das führt zu , die bestimmten Personen die Rechte und Berechtigungen für bestimmte Aktivitäten erteilt. einer Autorisierung Wie funktioniert die Authentifizierung? Um eine Person zu authentifizieren, können wir jeder Person eine eindeutige Phrase zuweisen. Wenn die Person die Phrase und ihren Namen richtig ausspricht, können wir sagen: „OK, wir haben die Person identifiziert.“ Dies ist der übliche Ansatz mit Benutzernamen und Passwörtern. Wenn die richtigen Anmeldeinformationen angegeben werden, betrachtet ein System die Identität als gültig und gewährt Zugriff. Dies wird als 1FA oder (SFA) bezeichnet. Single-Factor Authentication SFA gilt als ziemlich unsicher. Warum? Weil Benutzer notorisch schlecht darin sind, ihre Anmeldeinformationen sicher aufzubewahren. Die Multi-Faktor-Authentifizierung (MFA) ist eine sicherere Alternative, bei der Benutzer ihre Identität auf mehr als eine Weise nachweisen müssen. Einige dieser Möglichkeiten sind: Einmal-PIN-Nummern / OTP Von sicheren Drittanbietern ausgeführte Authentifizierungs-Apps (z. B. Google/Microsoft Authenticator) Biometrie Nach der Authentifizierung kann die Person weiterhin frei Aktionen in der Anwendung ausführen. Und die Anwendung soll die Person während ihrer gesamten Reise erkennen, ohne sie zu vergessen. Im Idealfall wäre es zu viel verlangt, den Benutzer jedes Mal, wenn er auf eine andere Seite wechselt oder eine Aktivität ausführt, nach dem Passwort zu fragen. Wir brauchen also eine Möglichkeit, den Benutzer authentifiziert zu halten, nachdem er seine Anmeldeinformationen eingegeben und einmal authentifiziert wurde. Dies wird als bezeichnet. Sitzungsverwaltung Zwei Möglichkeiten, die Authentifizierung des Benutzers aufrechtzuerhalten: : Wenn sich ein Benutzer über einen Browser bei einer Website anmeldet, erstellt der Server eine Sitzung für diesen Benutzer und weist ihm eine Sitzungs-ID zu. Diese Sitzungs-ID wird vom Server als Referenz gespeichert und an den Benutzer zurückgesendet, um in einem Cookie im Browser gespeichert zu werden. Jedes Mal, wenn der Benutzer nun eine Anfrage stellt, sendet der Browser die Sitzungs-ID zusammen mit der Anfrage. Dies hilft bei der Authentifizierung der Anfrage. Und so bleibt die Authentifizierung erhalten, während sich der Benutzer auf der Site befindet. Sitzungsbasierte Authentifizierung : Dazu erstellt der Server ein verschlüsseltes Token, das an den Benutzer gesendet und nur vom Browser als HttpOnly-Cookies gespeichert wird. Alle erforderlichen Informationen wie Benutzerinformationen, Berechtigungen und Ablaufdatum des Tokens sind im Token verschlüsselt. Das Token wird bei Aufrufen an den Server mitgeschickt. Der Server entschlüsselt das Token einfach mit dem geheimen Schlüssel und verifiziert den Benutzer. Dieses Token wird in regelmäßigen Abständen aktualisiert. Tokenbasierte Authentifizierung Der Hauptunterschied zwischen diesen beiden Ansätzen besteht darin, dass die tokenbasierte Authentifizierung ist, da das Token nicht auf der Serverseite gespeichert werden muss. Bei der sitzungsbasierten Authentifizierung muss das Token jedoch auch auf der Serverseite gespeichert werden, was sie macht. Dies führt zu Komplikationen, wenn das System skaliert wird oder die Anzahl der Benutzer wächst. zustandslos zustandsbehaftet Für die tokenbasierte Authentifizierung verwenden wir hauptsächlich JWTs (JSON Web Tokens). Wie funktioniert die Autorisierung? Sobald der Benutzer authentifiziert ist, müssen wir noch sicherstellen, dass er nur auf Ressourcen zugreifen darf, für die er die entsprechenden Berechtigungen hat. Unbefugter Zugriff auf vertrauliche Daten kann eine Katastrophe sein. Nach dem Prinzip der geringsten Privilegien richten Unternehmen normalerweise Zugriffsrichtlinien so ein, dass Sie standardmäßig Zugriff auf das haben, was Sie unbedingt benötigen. Und dann haben Sie in der Folge zusätzlichen Zugriff. Gängige Methoden zur Segmentierung des Zugriffs sind: : Benutzer werden einer bestimmten Gruppe/Rolle zugewiesen, die mit festgelegten Berechtigungen einhergeht. Beispiele: Administrator, Mitglied, Eigentümer. Rollenbasierte Zugriffskontrolle (RBAC) : Legt die Zugriffsrechte während der Autorisierung dynamisch anhand von Richtlinien und Regeln fest. Richtlinien basieren auf Benutzerrollen, Jobfunktionen und organisatorischen Anforderungen. Richtlinienbasierte Zugriffskontrolle (PBAC) : Benutzern wird der Zugriff entsprechend Attributen wie Titel, Zertifizierung, Schulung und/oder Umgebungsfaktoren wie Standort gestattet. Attributbasierte Zugriffskontrolle (ABAC) : Jeder Benutzer oder jede Entität verfügt über individuelle Berechtigungen, die ein- oder ausgeschaltet werden können, ähnlich wie beim Installieren einer neuen App auf Ihrem Telefon und der Entscheidung, welche Berechtigungen erteilt werden sollen (Standortdienste, Kontakte usw.). Zugriffskontrolllisten (ACLs) ACL wird häufig auf granularer Ebene verwendet als ABAC oder RBAC – beispielsweise, um einzelnen Benutzern Zugriff auf eine bestimmte Datei zu gewähren. ABAC und RBAC werden im Allgemeinen als unternehmensweite Richtlinien eingeführt. Entwurf eines Authentifizierungssystems Anforderungen Beginnen wir zunächst mit der Definition der des Systems: funktionalen Anforderungen : Ermöglicht Benutzern die Registrierung durch Angabe der erforderlichen Informationen. Registrierung : Authentifizieren Sie Benutzer anhand ihrer Anmeldeinformationen. Anmelden : Verwalten Sie Benutzersitzungen effizient, um die Sicherheit zu gewährleisten. Sitzungsverwaltung : Stellen Sie den Benutzern einen sicheren Prozess zur Wiederherstellung ihrer Kennwörter zur Verfügung. Kennwortwiederherstellung : Definieren Sie Rollen und Berechtigungen für verschiedene Benutzertypen. Zugriffskontrolle : Führen Sie zu Prüfzwecken detaillierte Protokolle der Authentifizierungsereignisse. Prüfpfad : Sorgen Sie für geringe Latenz und schnelle Reaktionszeiten. Leistung Im Rahmen dieses Artikels werden wir folgende nicht berücksichtigen: nicht-funktionale Anforderungen : Implementieren Sie ein robustes MFA-System. Multi-Faktor-Authentifizierung (MFA) : Priorisieren Sie die Datensicherheit durch Verschlüsselung, sichere Speicherung und sichere Kommunikation. Sicherheit : Konzipieren Sie das System so, dass es eine wachsende Zahl von Benutzern und Transaktionen bewältigen kann. Skalierbarkeit : Minimieren Sie Systemausfallzeiten und stellen Sie eine hohe Verfügbarkeit sicher. Zuverlässigkeit : Entwickeln Sie eine intuitive Benutzeroberfläche für ein nahtloses Erlebnis. Benutzerfreundlichkeit Kapazitätsschätzung Verkehrsschätzung Beginnen wir zunächst mit . Wir gehen von einem durchschnittlichen Datenverkehr von 100.000 pro Monat aus. Wir schätzen einen Benutzerverkehr von 100.000 pro Monat. Das entspricht 0,04 Anfragen pro Sekunde. Wir müssten in 90 % der Fälle innerhalb von 500 ms auf jede Anfrage antworten, d. h. wir benötigen eine p90-Latenz von 500 ms. der Verkehrsschätzung assumed_traffic_per_month = 100000 #requests assumed_traffic_per_day = assumed_traffic_per_month / 30 ~= 3350 (assuming on higher end; 3333.33 to be precise) estimated_time_per_request = 500 #ms; P90 of 500ms traffic_per_second = (assumed_traffic_per_month) / (30*24*60*60) = 0.04 : 500 ms (maximal akzeptable Latenz, unabhängig von der Systembelastung). Die durchschnittliche Kapazität, die eine Instanz zum Bearbeiten einer Anfrage benötigen kann, beträgt unseren Berechnungen zufolge etwa 35 ms, vorausgesetzt, dass für die jeweilige Anfrage keine aufwändige Verarbeitung stattfindet. Service Level Objective (SLO) Lassen Sie uns mithilfe der obigen Metriken zwei weitere generieren. abgeleitete Metriken : Akzeptabler Rückstand pro Instanz: Maximale Anzahl von Anfragen (Last), die von einer Instanz akzeptiert werden können, ohne das SLO zu beeinträchtigen. Kapazität : Rückstand pro Instanz: Gesamtzahl der Anfragen (Last), die basierend auf dem aktuellen Datenverkehr in eine Einheit/Instanz fließen. Nachfrage Daher, SLO = 500ms approx_response_time_for_one_request = 35 #ms capacity = SLO/approx_response_time_for_one_request = 500 / 35 ~= 20 load_on_one_instance = 0.04 instances_available = 1 demand = traffic_per_second / instances_available = 0.04 Berechnen wir anhand der Nachfrage und der verfügbaren Kapazität die Gesamtzahl der erforderlichen Instanzen. total_units_required = demand / capacity = 0.04 / 20 = 0.002 ~= 1 Somit könnten wir mit 1 Instanz problemlos 100.000 Anfragen pro Monat mit 0,04 Anfragen pro Sekunde verarbeiten. Dabei kann jede Einheit 20 Anfragen pro Sekunde verarbeiten, ohne das SLO zu beeinträchtigen. Speicherschätzung Idealerweise müssten wir die Benutzerdaten jedes Benutzers speichern, um den Authentifizierungs- und Autorisierungszugriff zu gewährleisten. Angenommen, 5 KB/Benutzer monthly_new_users = 500 monthly_additional_storage = 500 * 5kb = 2500kb ~= 2GB Wenn wir also 500 neue Benutzer aufnehmen, benötigen wir jeden Monat 2 GB mehr Speicherplatz. Für den Fall, dass wir Authentifizierungsprotokolle aufbewahren möchten. Für jede Authentifizierungsanforderung werden voraussichtlich 2 KB zum Speichern benötigt. auth_request_size = 2kb #assumption monthly_storage = monthly_visitors * auth_request_size = 100,000 * 2KB ~= 200MB Bei einem angenommenen monatlichen Datenverkehr von 100.000 bräuchten wir daher jeden Monat zusätzlich 200 MB. Datenbank Design Nachdem wir nun die Kapazitätsschätzung abgeschlossen haben, erstellen wir die Schemata der Datenbank, die zur Unterstützung der funktionalen Anforderungen erforderlich sind. Lassen Sie uns schnell die Tabellen durchgehen. Wir verwenden 6 Tabellen. Benutzer - Zum Speichern aller Benutzerinformationen Anmeldeinformationen – Zum Speichern der Zugriffs-/Aktualisierungsanmeldeinformationen, sobald der Benutzer autorisiert wurde. Passwörter – Zum Speichern der verschlüsselten Benutzerpasswörter. PasswordRequests – Zum Speichern der Kennwortänderungsanforderungen, die für einen bestimmten Benutzer eingehen. Sitzungen – Zum Speichern, wann der Benutzer eine aktive Sitzung hatte und wann seine letzte Aktivität stattfand. ActivityApproval – Zum Speichern von Genehmigungsanfragen für eine von einem bestimmten Benutzer ausgeführte Aktivität, die vom Administrator überprüft werden muss. High-Level-Design für das Authentifizierungssystem Systemendpunkte Endpunkt Beschreibung /Anmeldung Authentifizieren Sie die Benutzeranmeldeinformationen. /Ausloggen Benutzersitzung beenden und Authentifizierungstoken widerrufen. /registrieren Erstellen Sie einen neuen Benutzer. /update/:Benutzer-ID Benutzerinformationen aktualisieren. /löschen/:Benutzer-ID Löschen Sie ein Benutzerkonto. /grant/:Benutzer-ID/:Berechtigung Gewähren Sie einem Benutzer bestimmte Berechtigungen. /widerrufen/:Benutzer-ID/:Berechtigung Einem Benutzer die Berechtigungen entziehen. /check/:Benutzer-ID/:Ressource Überprüfen Sie den Zugriff des Benutzers auf eine bestimmte Ressource. /erstellen/:Benutzer-ID Erstellen Sie eine neue Benutzersitzung. /expire/:Sitzungs-ID Eine Benutzersitzung ablaufen lassen. /validieren/:Sitzungs-ID Validieren Sie eine aktive Benutzersitzung. Anforderungserfüllung Nachdem nun alles vorbereitet ist, wollen wir sehen, wie wir alle Anforderungen erfüllen können. Anmeldung – Wenn ein neuer Benutzer unsere Anwendung besucht. Wir müssen Benutzerdetails speichern, damit wir den Benutzer bei seinem nächsten Besuch autorisieren/identifizieren können. Anforderung – Wenn ein neuer Benutzer die Anwendung besucht und Benutzerdetails zusammen mit seiner E-Mail-Adresse und seinem Passwort eingibt. Dies wird in der Datenbank erfasst. Die Benutzerdetails werden in der Benutzertabelle gespeichert. Und das Passwort wird in verschlüsselter Form in der Anmeldeinformationstabelle gespeichert. Erfüllt Anmeldung – Wenn ein bestehender Benutzer unsere Anwendung besucht. Wir müssen den Benutzer identifizieren, damit wir seine Aktionen autorisieren/identifizieren und ihm die ihm gehörenden Daten anzeigen können. Anforderung – Wenn ein bestehender Benutzer die Anwendung besucht und seine Daten, E-Mail-Adresse und sein Passwort eingibt. Wir hashen das Passwort und vergleichen den Hash mit dem Hash, der für den Benutzer in der Anmeldeinformationstabelle gespeichert ist. Wenn es übereinstimmt, konnten wir den Benutzer erfolgreich identifizieren. Andernfalls muss er das korrekte Passwort eingeben, das er bei der Registrierung eingegeben hat. Dieser Vorgang wird als bezeichnet. Erfüllt Authentifizierung Sitzungsverwaltung - Wenn sich ein Benutzer durch Eingabe seines Benutzernamens und Passworts authentifiziert hat, müssen wir sicherstellen, dass er bei zukünftigen Aktionen bzw. beim Versuch, vertrauliche Daten anzuzeigen, angemeldet bleibt, ohne dass er sein Passwort immer wieder neu eingeben muss. Anforderung – Wenn sich der Benutzer erfolgreich authentifiziert. Der Authentifizierungsserver teilt dem Client zwei Token mit. Ein und ein . Das Zugriffstoken kann verschlüsselte Daten enthalten und hat aus Sicherheitsgründen eine kurze Ablaufzeit. Sobald der Client das Zugriffstoken hat, sendet er das Zugriffstoken zusammen mit jeder Anfrage zurück, was bei der Authentifizierung der Anfrage hilft. Wenn das Zugriffstoken abläuft, muss der Client mit dem bereitgestellten Aktualisierungstoken ein neues Zugriffstoken anfordern. Dies hilft bei der Aufrechterhaltung einer Sitzung. Erfüllt Zugriffstoken Aktualisierungstoken Passwort-Wiederherstellung : Wenn ein Benutzer sein Kennwort vergisst, muss er die Möglichkeit haben, es sicher zurückzusetzen. Anforderung - Wenn der Benutzer sein Passwort vergisst, kann er seine E-Mail-Adresse auf der Seite „Passwort vergessen“ eingeben. Wir generieren dann einen Einmalcode und senden den Link an seine E-Mail-Adresse. Wenn der Benutzer auf diesen Link mit dem Code und der E-Mail-Adresse klickt, können wir sicher feststellen, dass die Anfrage zur Passwortwiederherstellung authentisch ist. Und wir bieten dem Benutzer die Möglichkeit, sein neues Passwort festzulegen und so das Passwort wiederherstellen zu können. Erfüllt Zugangskontrolle – Wenn ein Benutzer eine bestimmte Aktion ausführt, müssen wir sicherstellen, dass der Benutzer für die Ausführung dieser Aktion authentifiziert ist und die Aktion erst dann zulassen. Anforderung – Wir führen der Einfachheit halber eine Liste mit Aktionen, sagen wir 1–12. Für jeden Benutzer führen wir die authentifizierten Aktionen für diesen Benutzer. Nehmen wir also an, der Benutzer versucht, eine Aktion mit der ID 4 auszuführen. Wir prüfen, ob der Benutzer die Berechtigung hat, Aktion 4 auszuführen. Wenn ja, fahren wir fort und schließen die Anfrage ab. Andernfalls zeigen wir an, dass die Anfrage aufgrund fehlender Berechtigungen nicht erfolgreich war. Erfüllt Buchungskontrolle - Im Falle eines Sicherheitsvorfalls sollten wir in der Lage sein, genügend Protokolle durchzusehen und einen plausiblen Grund dafür zu haben, was passiert sein könnte bzw. Hinweise auf eine mögliche Ursache zu haben. Anforderung – Für solche Szenarien können wir Protokolle für jede Authentifizierungsaktion führen, die auf dem Server stattfindet. (a). Für jede Anmeldeanforderung führen wir ein Protokoll darüber, wann die Authentifizierung erfolgte, von wo, IPs und andere relevante Details. (b). Für jede Anforderung zur Kennwortwiederherstellung führen wir ein Protokoll darüber, wann sie initiiert wurde, von wo, IPs, ob die Anforderung abgeschlossen war und andere relevante Details. (c). Darüber hinaus führen wir Protokolle, wenn ein Benutzer für eine Aktion autorisiert/nicht autorisiert wird und von wem. Diese Protokolle sollten insgesamt in der Lage sein, anzuzeigen, was passiert sein könnte, falls Sie versuchen, ein Szenario zu verstehen. Erfüllt Leistung – Die Leistungsanforderung beträgt, wie im Abschnitt zur Kapazitätsschätzung beschrieben, 0,04 Anfragen/Sekunde und 100.000 Anfragen pro Monat. Anforderung – Wir haben die Anforderung bereits mit genügend Servern im Abschnitt Kapazitätsschätzung erfüllt. Erfüllt Abschluss In diesem Artikel haben wir zunächst den Unterschied zwischen Authentifizierung und Autorisierung erklärt. Anschließend haben wir ein Authentifizierungs- und Autorisierungssystem erstellt. Dieses ist sicher, zuverlässig und bietet Leistung, während es gleichzeitig den Industriestandards entspricht und alle gewünschten Anforderungen erfüllt. In Zukunft werde ich möglicherweise bestimmte Teile des Artikels aktualisieren, damit er weiterhin relevant bleibt und um weitere Informationen und Einblicke in den Aufbau eines solchen Systems zu bieten.
