Identity- und Access Management im österreichischen Portalverbund. Vorlesungsreihe Trends in e-commerce

Transkript

1 Peter Pichler Identity- und Access Management im österreichischen Portalverbund Vorlesungsreihe Trends in e-commerce Land-, forst- und wasserwirtschaftliches Rechenzentrum GmbH, LFRZ System- & Software-Entwicklung, Agenda Einleitung / Überblick E-Government Portalverbund Entstehung mit ZMR als Motivation Architektur und Sicherheitsanforderungen Software Standardportal und LDAP-Tools Technik hikund dausblick blik(pt (Peter Pihl Pichler) Portalverbundprotokoll (PVP) Einbindung zusätzlicher Anwendergruppen Interoperabilität SAML

2 Unternehmen - LFRZ GmbH Land-, forst- und wasserwirtschaftliches Rechenzentrum GmbH 1968 vom BM für Landwirtschaft als Verein gegründet 2005 in GmbH umgewandelt IT-Dienstleister für den öffentlichen Bereich (ca. 50 MA) Softwareentwicklung (Java,.Net, PHP, Oracle) LDAP und Portalsoftware (Standardportal) GIS Geoinformations-Systeme Content Management Systeme (CMS) Rechenzentrum für Portale, CMS, GIS-, Datenbank- und Webanwendungen 3 Einleitung / Überblick E-Government Dipl.-Ing. (1961) Studium der Landwirtschaft an der BOKU in Wien Sojabohnenzüchtung / Sortenprüfung für Getreide in Wien LFRZ seit Websites und Webapplications Bereichsleiter E-Government Services Mitarbeit in E-Government Ab Arbeitsgruppen LDAP und Portalverbund Laufen, Alte Musik, Bird Watching 4 2

3 Was ist E-Government? Definition lt. Wikipedia (auch E-Administration): Unter E-Government im engeren Sinn (elektronisches Regieren und Verwalten) versteht man die Vereinfachung und Durchführung von Prozessen zur Information, Kommunikation und Transaktion innerhalb und zwischen Institutionen der Exekutive (Behörden), sowie zwischen diesen Institutionen und Bürgern (G2C), Unternehmen (G2B) und weiteren staatlichen Institutionen (G2G) durch den Einsatz von Informations- und Kommunikationstechnologien. Synonym für eine moderne und effiziente Verwaltung Weitere Infos auf Plattform Digitales Österreich 5 Themen des E-Government - Einordnung Portalverbund Bürger Online Verfahren (z.b. Steuererklärung Finanz Online) Help.gv.at (Plattform mit Abbildung von Lebenssituationen) Bürgerkarte (sichere Authentifizierung und Transaktionen im Internet) Unternehmen Elektronische Zustellung E-Procurement Elektronische Beschaffung Verwaltung Elektronischer Akt Portalverbund (Zugang zu Behördenanwendungen) 6 3

4 Motivation für Portalverbund - Behördenapplikation ZMR Zentrales Melderegister (ZMR) Kern ist das Personenregister mit allen natürlichen Personen die in Österreich einen oder mehrere Wohnsitze haben Alle Meldebehörden (Gemeinden) und Standesämter benötigen schreibenden Zugriff zwecks Erfassung und Aktualisierung der Daten Abfragemöglichkeit für alle Behörden und die Wirtschaft (Rechtsanwälte, Notare, Banken, Versicherungen, ) Rechtsgrundlage ist das Meldegesetz mit der Meldegesetzdurchführungsverordnung aus dem Jahr 2001 Für E-Government Basis für die Identifikation von Personen (z.b. Personenbindung auf Bürgerkarte) 7 Challenge Benutzerstruktur ZMR 8 4

5 Unterschiedliche Benutzerrechte bei ZMR Meldebehörde > ZMR-Anfrage, ZMR-Update Personenstandsbehörden > ZMR-Standesamt Behörden (alle) > ZMR-Behördenabfrage Fremdenpolizeibehörden > ZMR- Fremdenpolizeianfrage Polizei und Justiz > ZMR-Verknüpfungsanfrage Wissen wer welche Rechte wahrnehmen soll, liegt in der Regel bei den jeweiligen Behörden (z.b. bei Gemeinde) 9 Idee Portalverbund mit delegierter Benutzerverwaltung Benutzer sollen nicht mehr in Applikation sondern in eigenen dezentralen Portalen verwaltet werden Zusammenschluss von Portalen für User (Stammportale) und Anwendungen (Anwendungsportale) Portalverbund Anwendung gibt Rechte vor; Zuweisung erfolgt im Portal der zuständigen Verwaltungseinheit (Ministerium, Land, Gemeinde,..) delegierte Benutzerverwaltung Idee wurde 1999/2000 entwickelt und bis 2002 realisiert 10 5

6 Lösung mit Portalverbund 11 Was ist der Portalverbund? Sichere Verbindung von verteilten Stamm- und Anwendungsportalen über Portalverbundprotokoll (PVP) konzeptionell: Web of Trust technisch: ein Extranet, Umsetzung durch das Portalverbundprotokoll Rechtsgrundlage Portalverbundvereinbarung (PVV 1.0) 12 6

7 Portalverbundvereinbarung Vereinbarung zwischen Portalbetreibern und Anwendungsverantwortlichen Ziel ist geregelter Zugang zu Anwendungen der Verwaltung durch BenutzerInnen aus der Verwaltung Rechte und Pflichten aller Beteiligten werden festgelegt Beitrittserklärung für Teilnahme am Portalverbund und die Meldung der Anwendungen 13 Portalverbund Architektur 14 7

8 Sicherheitskonzept im Portalverbund basierend auf Rollenkonzept (Sammlung von Anwendungsrechten) strukturierte Anwenderverwaltung im Stammportal eingeschränkter Zugang mittels SSL Client-Zertifikate Nutzung erfolgt unter Anwendung der Spezifikation der Sicherheitsklassen (SecClass 2.1.0) SecClass 1 erfordert nur Wissen (UID/PW) SecClass 2 erfordert Wissen und Besitz SecClass 3 Wissen und Besitz an in einem geschützten Bereich betriebenen Gerät 15 Sicherheitsanforderungen im Portalverbund werden durch 4 Komponenten definiert Art der Authentifizierung des Anwenders geheimes Wissen (Passwort), Besitz (HW-Token, Bürgerkarte) Art der Identifizierung des Anwenders Identifizierung mit Ausweis, ZMR-Abfrage des Anwenders IT-Grundschutz/Sicherheitskonzept Schutz der IT-Infrastruktur, Aufstellung Geräte Personelle Maßnahmen Grundschulung + Spezialschulung, Verpflichtungserklärung 16 8

9 Sicherheitsklasse der Anwendung Einteilung erfolgt nach Art der Daten (DSG) und der Vertraulichkeit SecClass 0 -> Frei verfügbare Informationen SecClass 1 -> Abfrage von personenbezogenen Daten, die für jedermann zugänglich ist (z.b. Meldauskunft) SecClass 2 -> Transaktion auf personenbezogene Daten (z.b. ZMR-Update) SecClass 3 -> Transaktion auf sensible Daten (EKIS-Abfrage) 17 Vorteile des Portalverbunds Portalverbund kann für alle Behördenanwendungen genutzt werden (EKIS, Firmenbuch, Grundbuch, Rechtsdatenbank, u.v.a) Benutzerdaten werden dort verwaltet wo sie anfallen geringerer Aufwand und geringere Kosten Benutzerdaten werden nur einmal gewartet nicht in x Applikationen bessere Datenqualität AnwenderInnen können mit einem Account auf eine Vielzahl von Anwendungen zugreifen User brauchen sich nicht 100 Passwörter merken Beim Ausscheiden von Personen genügt Sperren eines Accounts geringeres Sicherheitsrisiko 18 9

10 Standardportal - Software für Portalverbund entwickelt in Kooperation zwischen BM.I und LFRZ Referenzimplementierung für den österr. Portalverbund Datenbasis ist LDAP-gv.at Single Sign-On in Windows-Netzwerken mit Kerberos Login mit Bürgerkarte oder Dienstkarte t (MOA-ID) OpenSource Komponenten (Java, Tomcat, SOAP) mehrsprachige, erweiterbare HTML-Oberflächen 19 Stammportal Login - Anwendungsliste 20 10

11 Vorteile des Standardportals Modulare SW-Architektur Plugin Konzepte für individuelle Erweiterungen plattformunabhängig, skalierbar für hohe Performance LA und User-Group für gemeinsame Weiterentwicklung Software Wartung und Weiterentwicklung durch LFRZ großer Nutzerkreis 5 Ministerien (BKA, BMI, BMJ, BMLFUW, BMGFJ) Burgenland, Kärnten, NÖ, OÖ, Salzburg, Steiermark, Vorarlberg Hauptverband, Statistik Austria, BEV, UBA, ÖGIZIN, 21 Benutzer- und Rechteverwaltung Zur Administration von Stammportalen BenutzerInnen verwalten und Rechte zuordnen Gruppen verwalten Rechteeinsicht Systeme (SOAP) anlegen Daten importieren u. exportieren 22 11

12 Awendungsportalverwaltung (SU-ZMR) Zur Administration von Anwendungsportalen Anwendungen und dazugehörige Rechte verwalten Stammportale und zugriffs- berechtigte Stellen einrichten Portalzertifkate verwalten 23 Technik und Ausblick Peter Pichler; Entwicklungsleitung Standardportal OOA, OOD, Java Entwicklung IT Securitiy HTTP und SOAP Seit 2002 mit PVP beschäftigt; seit 2005 ausschließlich Mitarbeit in mehreren Arbeitsgruppen der AGIZ 24 12

13 PVP Das Portalverbundprotokoll Die AnwenderIn authentifiziert sich am Stammportal, das Stammportal am Anwendungsportal Das Stammportal teilt mit, welche Anwendungsrechte der BenutzerIn eingeräumt werden sollen Das Anwendungsportal prüft, ob die gemeldeten Rechte von Mitarbeitern der anfragenden Organisation verwendet werden können. Zulässige Zugriffe werden an die Zielanwendung weitergeleitet. Diese realisiert die Rechte. 25 Peter Pichler PVP Aus technischer Sicht PVP Portale sind HTTP-Reverse-Proxy-Server (sie nehmen HTTP- Request entgegen, terminieren die SSL-Verbindung und bauen eine neue HTTPS Verbindung zum Zielserver auf; Gegenteil zu einem Reverse-Proxy ist ein Transparenter Proxy) PVP ist für HTTP und für SOAP definiert. Die PVP Parameter (Informationen) werden je nach Protokoll entweder als HTTP bzw. als SOAP Header Parameter übergeben Die PVP Portalinfrastruktur ist für Authentifizierung und Autorisierung von NutzerInnen anderer Behörden zuständig. 26 Peter Pichler 13

14 PVP Portale und Anwendungen PVP entlastet die Anwendungen von der Aufgabe Benutzer- und Rechtedaten zu verwalten und AnwenderInnen zu authentifizieren. (sowohl technisch als auch organisatorisch!!!) PVP Anwendungen folgen dem Konzept der Role Based Autorisation JEDES Dürfen wird aus den über PVP gemeldeten Rechten abgeleitet PVP Anwendungen sollen Reverse-Proxy-fähig sein (d.h. keine absoluten Referenzen auf sicherheitsrelevante Folgeressourcen) 27 Peter Pichler PVP Parameter / Informationen des Stammportals an das Anwendungsportal bzw. die Anwendung X-Version: 1.8 X-AUTHENTICATE-gvSecClass: 2 X-AUTHENTICATE-gvGid: AT:VKZ:UFB w:t839 X-AUTHENTICATE-bpk: bpk:pv:rfjnt0yqwqruf5x/xb2kzcxz0fc= X-AUTHENTICATE-cn: Peter Pichler X-AUTHENTICATE-UserID: peter.pichler@lfrz.at X-AUTHENTICAT peter.pichler@lfrz.at X-AUTHENTICATE-tel: X-AUTHENTICATE-participantId: AT:VKZ:UFB w X-AUTHENTICATE-gvOuId: AT:VKZ:UFB w X-AUTHENTICATE-Ou: LFRZ X-AUTHORIZE-roles: PTLV_AWP_ADMIN(ORG_ID=AT:VKZ:UFB w) Identifikation, Wiedererkennung Kontakt Organisatorische Zugehörigkeit Rechte (Rollen) 28 Peter Pichler 14

15 PVP Rechte Rechte werden am Stammportal ermittelt und als Strings an das Anwendungsportal (bzw. die Anwendung) weitergegeben Welche Rechte zur Verfügung stehen, und wie diese aufgebaut sind, definiert die Anwendung. (die Anwendungsbetreiberin) Die Anwendung beschreibt Ihr Rechtesystem (Meta-Modell) Rechte können mit beliebig vielen Parametern genauer definiert werden. (welche Parameter-namen und -werte zulässig sind definiert das Rechte-Meta-Modell) Die Rechte werden von der Anwendung umgesetzt 29 Peter Pichler PVP Rechte - Aufbau X-AUTHORIZE-roles: PTLV_ AWP_ ADMIN(ORG_ ID=AT:VKZ:UFB w) Alle Rechte des Benutzers werden mit diesem Header ausgedrückt! Format: Recht1(Parameter1=Wert1,Parameter2=...);Recht2(...)... Es können beliebig viele Rechte mit beliebig vielen Parametern verwendet werden. Aufgrund der vertraglichen Vereinbarungen besteht Sicherheit, dass Rechte nur befugten Mitarbeitern zugeordnet werden. Die Portalinfrastruktur stellt sicher, dass nur gültige der Sicherheitsklasse entsprechende und der Organisation des Benutzers zustehende Rechte an die Anwendung übertragen werden. 30 Peter Pichler 15

16 Grenzen des PVP Rechtesystems Alle durch Rechteverwalterinnen festzulegende Möglichkeiten können mit PVP Rechten abzubilden!!! Objektbezogene Rechte (Spezifische Rechte auf während der Anwendungsbenutzung entstehende Objekte) werden nicht über PVP kommuniziert Beispiel: In einem Redaktionssystem sollen die Benutzer die Möglichkeit haben, selbst erstellte Artikel einer Kollegin zur Bearbeitung freizuschalten 31 Peter Pichler Passiver Benutzerdatenabgleich über das Anwendungsportal Integration von Alt- und Standardanwendungen Ein ApplicationAdapter legt Benutzerdaten an und simuliert eine Anmeldung. Z.B. Citrix Anbindung des BKA 32 Peter Pichler 3 16

17 PVP Features PVP erlaubt es für einen die Benutzerdaten und Anwendungsrechte für alle österreichischen Behördenanwendungen am Stammportal jener Einrichtung zu verwalten, die die MitarbeiterIn beschäftigt. Die Prozesse und Zuständigkeiten für Einrichtung und den Entzug von Anwendungsrechten können klar geregelt werden. Die Datenqualtiät von Zugriffsinformationen steigt Die SecClass Spezifikation bietet ein gemeinsames Sicherheitsregime für alle Behördenanwendungen (1, 2 oder 3) Aufgrund der genormten Beschreibung des Aufbaus von PVP- Rechten (Meta-Modell), ist es möglich, generische Anwendungen für die Benutzer- und Rechteverwaltung zu entwickeln. 33 Peter Pichler PVP Features Teil2 Die PVP Infrastruktur bildet eine Application-Firewall, die Sicherstellt, dass nur Zugriffe von berechtigten BenutzerInnen an die Anwendung weitergeleitet werden. Zugriffe werden einheitlich protokolliert Rechtliche Fragen der zwischen-behördlichen Zusammenarbeit sind über die Portalverbundvereinbarung geregelt PVP ist tragender Teil der österreichischen E-Government Strategie. Alle neu entwickelten Behördenanwendungen sollen PVP konform umgesetzt werden 34 Peter Pichler 17

18 PVP... Stand der Entwicklung Teil I Der Portalverbund wurde entwickelt um es für Behörden einfacher zu machen, anderen Gouvernment-Organisationen auf eigene Anwendungen zugreifen zu lassen. Alle Bundesministerien, alle Landesregierungen und alle Gemeinden verfügen über PVP Infrastruktur. (Stammportale) Manche PVP Nutzer verwenden die PVP-Infrastruktur wieder, um Bürgern Zugang zu eigenen Anwendung zu ermöglichen. (z.b. die Landesregierungen g Oberösterreich, Steiermark und Salzburg, das Bundeskanzleramt, das Landwirtschaftsministerium, BM.I) Notariatskammer betreibt ein eigenes PVP Portal und bietet Ihren Mitgliedern im Rahmen eigener Vereinbarungen Zugang zu Anwendungen der Justiz und des Innenministeriums an 35 Peter Pichler PVP... Stand der Entwicklung Teil II Für den Betrieb von Portalen und für die Verwaltung den notwendigen ldap-datenbstände steht Standardsoftware zur Verfügung Eine Inter-Behörden Arbeitsgruppe (AGIZ; Arbeitsgruppe Integration&Zugänge; vormals QPV) koordiniert die Weiterentwicklung des Protokolls und behandelt Probleme bei der Zusammenarbeit PVP erleichtert die Entwicklung von Behördenanwendungen sowie die sichere Verwaltung von BenutzerInnendaten und Zugriffsrechten. ldap.gv.at at konsolidiert sich zum zentralen Verzeichnis aller österreichischen Behörden und zur Datendrehscheibe für den Portalverbund. (Daten über Organisationen, Anwendungen, Stammportale, Dienstleistervereinbarungen) Verschiedene Sicherheitsanforderungen können mit einer einheitlichen Systematik abgedeckt werden. 36 Peter Pichler 18

19 PVP Ausblick / Andere Benutzergruppen / Unternehmen bzw. Landwirte Große Ähnlichkeit zum PVP Use-Case Case. Unternehmen bzw. Landwirte sollen selbst (über eine bevollmächtigte Benutzer- und Rechteverwalterin) festlegen, welche MitarbeiterIn für welche elektronische Kommunikation mit welchen Behörden zuständig ist. (Finanzamt, Meldungen beim Umweltbundesamt, bei der Datenschutzkommision, AMA, Statistik Austria,...). Erster Schwerpunkt soll die Buisiness->Goverment Kommunikation sein. In weiterer Folge könnten die Infrastrukturen auch für Business->Business Kommunikation verwendet werden. (z.b. KSV Anfragen, Interaktion mit Spediteuren und Lieferservices, Benutzung elektronischer Bestellsysteme,...) 37 Peter Pichler PVP Ausblick / Andere Benutzergruppen / Bürgerportale Einheitliches Authentifizierungssystem für Bürger->Goverment Sicherheitsregime ähnlich zum Portalverbund Soll aus datenschutztechnischen Überlegungen heraus, ebenfalls als Verbund von Portalen aufgebaut werden. (Bürger wählt das Portal seines Vertrauens) Ähnlich wie Unternehmen, können Bürger anderen konkrete Vertretungsrechte (z.b. Finanz-Online für Steuerberater) vergeben. Einheitliches Protokoll für die Behörden-Zielanwendungen Auch in diesem Bereich besteht das Potential die Infrastruktur für Bürger->Business Anwendungen wiederzuverwenden. 38 Peter Pichler 19

20 PVP Ausblick / PVP 2.0 goes SAML In der Version 2.0 soll PVP mithilfe von SAML Datenstrukturen ausgedrückt werden (internationale Vermarktbarkeit) Die PVP-Infrastruktur nach den Aufgaben Identity-Provider (Authentifizierung), Attribute-Provider (Zusatzinformationen und Autorisierung) und Sevice-Provider (Anwendung inklusive der Funktion des Anwendungsportals) strukturiert 39 Peter Pichler PVP Ausblick / SAML und das PVP Standardportal Anmeldung am Stammportal über SAML PVP-Stammportale sollen die Anmeldung von anderer SAML Identity Providern übernehmen können. Anmeldung an der Anwendung über SAML. (Anwendungsportal->Anwendung) Immer mehr Anwendungen unterstützen Single-Sign-On über SAML. PVP Anwendungsportale werden zur PVP->SAML Bridge um solche Anwendungen einfach in den Portalverbund integrieren zu können. 40 Peter Pichler 20

21 Zusammenfassung PVP löst in der Behördenzusammenarbeit Probleme, für die es keine alternativen Lösungsansätze gibt PVP entlastet Anwendungen von der Aufgabe der Verwaltung von Benutzern und deren Rechten. Redundant geführte Benutzerdatenbestände werden eliminiert. PVP bietet ein abstraktes Rechtesystem, das formalisiert beschreibbar ist Rund um den Portalverbund wurden Prozesse zur Verwaltung von Benutzerdaten und Berechtigungen eingeführt Es existieren komfortable Werkzeuge für die Verwaltung von Anwendungen und Benutzerdaten. 41 Peter Pichler Zusammenfassung - Fortsetzung Sicherheitsanforderungen h it können anhand eines klar vorgegebenen Rahmenplans (Spezifikation SecClass) festgelegt werden. (0 bis 3) Die PVP Infrastruktur ist erprobt und wird ständig Reviews- und Security- Checks unterzogen. Die Sicherheit von Authentifizierung- und Autorisierung ist gelöst und muss nicht für jede weitere Anwendung neu erfunden werden. Mehrere hundert Anwendungen werden schon heute über PVP Technologie angeboten. Viele Anwendungen beginnen als interne Anwendungen und werden später um Funktionen erweitert, die für andere Benutzern (anderen Behörden, Bürgern,...) vorgesehen sind. Darum sollen alle neu entwickelten Behördenanwendungen schon von Anfang an PVP konform entwickelt werden. (Reverse-Proxy fähig, Rollenbasiertes Rechtesystem) 42 Peter Pichler 21

22 Informationen Referenten / Ansprechpartner Peter Pichler +43 (1) /232 DW +43 (664) gerold.pesendorfer@lfrz.at peter.pichler@lfrz.at Links / Portal LDAP.gv-at 43 Peter Pichler 22