IT Security Januar / Februar 2024

Weitere Magazine

Empfehlungen

Info

42 | IT SECURITY Alte Apps Business Logic Entitlements Momentaner Zustand Business Logic Entitlements Angestrebter Zustand Business Logic SC* ches Tooling für CI/CD Pipelines und deren Automation anbieten, überrascht es kaum, dass mit CEDAR auch eine Beschreibungssprache von AWS um Aufmerksamkeit buhlt. User Managements Business Logic Entitlements User Managements Business Logic Entitlements User Managements Business Logic Entitlements Business Logic Entitlements Softwareentwickler verwenden in realen Projekten oft flexibleren Code für Zugriffsentscheidungen. Die relevante Logik bleibt jedoch im Programmcode verborgen, schwer zu warten und intransparent. Um den Trend zur Auslagerung und Zentralisierung fortzusetzen, sollte demnach nur noch die reine Business-Logik in der Applikation verbleiben, während eine externe und technologisch standardisierte Komponente die Zugriffsentscheidungen aufgrund zentral definierter Policies trifft. In einem Gesamtschaubild könnte eine mögliche Architektur dann wie rechts abgebildet aussehen. AD für Benutzer- Management und SSO Business Logic Business Logic Bild 3: Evolutionsstufen der Auslagerung von Anwendungskomponenten SC* SC* ren. Damit ist OPA ist eine Implementierungsoption für den PDP, die sich zudem verhältnismäßig einfach in neue Softwareprojekte einbinden lässt. Da Softwareentwicklung heute primär für die Cloud in der Cloud stattfindet und Anbieter wie AWS ein umfangrei- IGA: Identity Governance & Administration IGA für Identity Management AM für grobgranularen Zugriff Authorization Services für feingranularen Zugriff user directory Eine Reihe von weiteren Anbietern wie Aserto, Sgnl und Co. nutzen intern den OPA als generische Komponente, um darauf aufbauend umfassendere Dienste und Funktionen anbieten zu können, während andere wie PlainID eigene Implementierungen bevorzugen. Viele Lösungsansätze – eine abstrakte Lösung Diese Ansätze verfolgen das Ziel, effiziente, wiederverwendbare und sichere Policies zur Autorisierung zu formulieren und diese zur Laufzeit der Anwendung performant auszuwerten. Im Gegensatz zur Authentisierungsschicht, die sich auf die Identität des Benutzers konzentriert, berücksichtigen Zugriffsentscheidungen in der Regel drei Aspekte: ➤ ein Subjekt (wer): Der agierende Benutzer, welcher eine Aktion ausführen möchte, ➤ eine Aktion, zum Beispiel „bearbeiten“ oder „löschen“, Bild 4: komplett reduzierter Ansatz für die Auslagerung der Autorisierung Eine Herausforderung – viele Lösungsansätze Bei der Suche nach Umsetzungsoptionen für Zugriffssteuerung kann die Vielzahl neuer Ansätze schnell überwältigend sein. Ein bekannter Vertreter ist der Open Policy Agent (OPA). Dieses Open-Source-Projekt erfreut sich in der Entwickler-Community großer Beliebtheit. OPA nutzt die eigene Beschreibungssprache REGO, um klare Policies für Zugriffsentscheidungen zu formulie- IdP: Identity Provider Authentication user Single Sign-On SAML OICDC/OAuth Application Identity Data Permission Enforcement Application Identity Data Permission Enforcement Policy Decision Point Januar/Februar 2024 | www.it-daily.net
IT SECURITY | 43 ➤ eine Ressource, auf welcher die Aktion ausgeführt werden soll, etwa ein Dokument oder eine Datei Diese „Triplets“ aus SUBJEKT, AKTION und RESOURCE werden in Policies verwendet, um die Anforderungen für gewährte oder verweigerte Zugriffe zu formulieren. Eine Beispiel-Policy könnte besagen, dass „eine Ressource nur gelöscht werden darf, wenn das Subjekt sich per MFA angemeldet hat und entweder Mitglied in der Gruppe „admin“ ist ODER Eigentümer der Ressource“. Listing 2 zeigt, wie solch eine Policy am Beispiel von REGO mit dem Open Policy Agent umgesetzt werden könnte: Standardmäßig wird Zugriff verweigert (Zeile 2 als Default-Wert). In den folgenden Zeilen werden Teil-Policies geprüft: Ist das Subjekt in bekannter Gruppe (Zeile 4-8), bzw. ist es Ressourceneigentümer (Zeile 9-11) oder per MFA authentifiziert (Zeile 12-15). Das Herzstück der Policy sind die Bedingungen in den darauffolgenden Blöcken (Zeile 16-27), die die Anforderungen kombinieren und nur bei Erfüllung „true“ für das Policy-Ergebnis „allow“ zurückgeben. Mit einer solchen Policy kann eine Anwendung alle Autorisierungsentscheidungen an einen externen PDP wie den Open Policy Agent auslagern. Die Anwendung muss nur den Kontext mitliefern: Subjekt, Ressource und Aktion. Die Entscheidung des PDP („allow“) wird von der Anwendung ausgewertet und umgesetzt. Das Beispiel zeigt die Grundprinzipien, ohne fortgeschrittene Techniken wie wiederverwendbare Sub-Policies oder externe Datenbankintegration als Policy Information Service (PIP). Dennoch demonstriert es die Stärke des Ansatzes: LISTING 2 1 authz.check_permission 2 default allow := false 3 allowed_groups := [‟admin”, ‟member”] # required user groups 4 # check if user has required group 5 group_permitted if { 6 user_group := input.group 7 user_group in allowed_groups 8 } 9 resource_owner if { 10 input.resource.owner == input.user 11 } 12 # check if user has MFA enabled 13 mfa_enabled if { 14 input.mfa == true 15 } 16 # allow if: mfa-enabled AND user in permitted group 17 allow if { 18 mfa_enabled == true 19 input.action == ‟delete” 20 group_permitted == true 21 } 22 # OR allow if: mfa-enabled AND user is resource owner 23 allow if { 24 mfa_enabled == true 25 input.action == ‟delete” 26 resource_owner == true 27 } ➤ Zugriffsregeln werden in einer universellen Beschreibungssprache formuliert und im zentralen Policy-Register gesammelt. ➤ Policies können einen gemanagten Review- und Freigabeprozess durchlaufen. ➤ Die Entscheidungslogik wird an einen PDP delegiert, der Auswertung und Protokollierung vereinheitlicht. ➤ Feingranulares Zugriffsmanagement kann konsistent über die gesamte Applikationslandschaft realisiert werden, dank einer universellen Beschreibungssprache, und unabhängig von der Programmierumgebung der jeweiligen Anwendung. Fazit Das Thema feingranulare Autorisierung ist für alle Unternehmen mit eigenen Projekten in der Softwareentwicklung ein relevanter Agendapunkt für den Austausch zwischen CTO, CIO und der Anwendungsentwicklung. Gerade bei agilen Entwicklungsprojekten und einem dynamischen Umfeld in der IT sollte über eine weitergehende Zentralisierung des Access Management und eine Ergänzung um Authorization Services nachgedacht werden. Für lediglich „konsumierende“ IT-Abteilungen mit vornehmlich SaaS-basierten externen Services kann FGA zwar interessant sein, allerdings wird die Anwendung hier eher auf Attribut- und Kontext-bezogene Policy-Erweiterung für einfache „JA/NEIN“ Entscheidungen limitiert, da eine direkte Anpassung der Applikationslogik häufig nicht möglich ist. Sebastian Rohr, Roland Baum https://www.umbrella.associates/ www.it-daily.net | Januar/Februar 2024
Seite 1 und 2: Detect. Protect. Respond. Januar/Fe
Seite 3 und 4: INHALT | 3 Inhalt 04 COVERSTORY 4 E
Seite 5 und 6: COVERSTORY | 5 DIE VERMITTLUNG VON
Seite 7 und 8: IT SECURITY | 7 Was sind ihre Top-p
Seite 9 und 10: IT SECURITY | 9 Quelle: Gerd Altman
Seite 11 und 12: IT SECURITY | 11 Cyber sicherheitse
Seite 13 und 14: IT SECURITY | 13 zahl von Kontextin
Seite 15 und 16: IT SECURITY | 15 SO LANGE DAUERT ES
Seite 17 und 18: IT SECURITY | 17 einstieg in Kali L
Seite 19 und 20: IT SECURITY | 19 Die Krux also: Die
Seite 21 und 22: IT SECURITY | 21 lungen oder verein
Seite 23 und 24: IT SECURITY | 23 Fragmentierung und
Seite 25 und 26: IT SECURITY | 25 Die Verhaltenslüc
Seite 27 und 28: IT SECURITY | 27 gangsformat entspr
Seite 29 und 30: IT SECURITY | 29 sichere dateien in
Seite 31 und 32: IT SECURITY | 31 Zero Trust GANZHEI
Seite 33 und 34: IT SECURITY | 33 Ulrich Parthier: W
Seite 35 und 36: IT SECURITY | 35 geführt werden. D
Seite 37 und 38: IT SECURITY | 37 gehörten OWASP AP
Seite 39 und 40: IT SECURITY | 39 passwort managemen
Seite 41: IT SECURITY | 41 PAP 1. View record
Seite 45 und 46: IT SECURITY | 45 funktionsweise von
Seite 47 und 48: Cyberkriminelle überall da tut Hil

IT Security Januar / Februar 2024

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?