Archive for the Category » ICT «

Fragwürdiger Artikel zur SuisseID

Die SuisseID ist seit über einem Monat lanciert. Erst ein mal ein grosses Lob an das gesamte Team und deren Partner. Sie haben es geschafft in sehr kurzer Zeit die Spezifikation zu entwerfen und diese zu einem grossen Teil zu implementieren.

Für diejenigen, die nicht wissen was die SuisseID ist, hier ein Ausschnitt aus Wikipedia:

Die SuisseID ist der erste standardisierte elektronische Identitätsnachweis der Schweiz, mit dem sowohl eine rechtsgültige elektronische Signatur wie auch eine sichere Authentifizierung (Log-in) möglich sind. Mit der als USB-Stick oder Chipkarte erhältlichen SuisseID können Geschäfte von Privatpersonen mit Firmen bzw. Verwaltungen direkt und sicher über das Internet oder per E-Mail abgeschlossen werden.

Jeder, der sich noch weiter für die SuisseID interessiert, kann auch einen Blick in ihre Spezifikation werfen.

Habe kürzlich einen Artikel in der Weltwoche entdeckt Teure Lösung für nichtexistente Probleme, welcher sich kritisch über die SuisseID äussert.

Als ich den Artikel gelesen habe, hat es mir fast die Sprache verschlagen. Eine solche Schwarzmalerei und unsachgemässe Recherche kann man ja vom Blick erwarten 😉 aber die Weltwoche scheint da wohl nicht besser zu sein. Der Autor schreibt frei aus der Seele und lästert über die SuisseID, hat wohl aber selber nie die Spezifikation der SuisseID gelesen und deren eigentlichen Zweck begriffen. Er stempelt sie als proprietäres, eigenbrötlerisches Schweizer Produkt ab, welches “eine digitale Mauer um unser Land” darstellt. Dabei basiert die SuisseID auf offenen Standards und lässt die Integration in bestehende Infrastruktur grundsätzlich zu.
Der Autor hätte sich mit einem Fachmann zusammensetzen sollen, bevor er den Artikel schrieb. Dies hilft, dass die Schere zwischen Endanwender und “IT Freak” nicht zu weit auseinanderklafft und beide Parteien einen Dialog führen, damit eine (gute) Lösung nicht wieder einmal in Vergessenheit gerät ohne jemals ihren wahren Nutzen erfahren zu haben. Anstatt nur auf die SuisseID in der Presse einzuprügeln und die Leute somit zu bekehren, sollte man als Autor versuchen das SuisseID Projekt und die technischen Möglichkeiten und Einschränkungen zu verstehen und somit sachgemäss über das Produkt zu berichten. Ja, es sind 21 Millionen CHF auf dem Spiel. Und mit solchen Artikeln muss man sich nicht wundern, wenn am Schluss niemand davon Gebrauch macht und das Geld verpufft.

Ich möchte nun selber Stellung nehmen zu einigen Punkten, welche im Artikel erwähnt werden:

Nun, ich kaufe heute schon meine Konzerttickets online, auch die Fahrscheine für Zugfahrten bei der SBB, ich nutze Telebanking, bestelle online bei diversen Shops Waren, usw. Wo genau liegt das Problem? Bei all diesen Angeboten habe ich mich einmal registriert und nutze sie fortan problemlos.

Ja das ist ja schön und recht. Soll von mir aus auch weiterhin so bleiben. Zwar ärgerlich, dass man für jede Seite oder jedes Angebot einen zusätzlichen Benutzernamen und Passwort braucht. Verleitet doch den Benutzer dazu sehr einfache Passwörter zu gebrauchen und dazu meistens immer das gleiche. Dank Phishing & Co. kann man schlimmstensfalls nach Herausinfden des Passworts auf all diejenigen Angebote zugreifen.
Da sehe ich den Vorteil einer SuisseID oder eines SAML Tokens. Kryptologisch betrachtet ist es sehr viel sicherer (SmartCard mit persönlicher PIN, Biometrie wäre noch besser) zudem braucht man sich nur noch einen PIN Code zu merken. Nämlich den PIN Code der SuisseID bzw. des SAML Tokens oder der Informaton Card (SuisseID unterstützt diese Formate).

Wir sind eine Exportnation, unsere Geschäftspartner im Ausland werden mit der SuisseID wohl kaum viel anfangen können. Kommt dazu, dass zwischen Unternehmen meistens eine langfristige Beziehung besteht und es somit auch da kaum Probleme mit nicht vorhandenen digitalen Unterschriften gibt.

Die Frage hier ist nicht ob die Geschäftspartner was mit der SuisseID anfangen. Die Frage ist, ob sie was mit digitalen Unterschriften anfangen können. Ob hinter der digitalen Unterschrift eine SuisseID dahintersteckt, oder eine BELPIC (Belgien) oder eine BULSTAT (Bulgarien) uvm, spielt keine grosse Rolle. Das wichtigste ist hierbei, dass das darunterliegende Zertifikat und Krypto-Verfahren standardisiert ist. Und dies ist bei der SuisseID ebenfalls der Fall. Welche EU Länder bereits schon eGov-Vorstösse wie die SuisseID betreiben oder solche Lösungen bereits schon realisiert haben findet man in der eID Interoperability for Pan-European eGovernment Services.

Das letzte Beispiel, welches jeweils angeführt wird, ist die Alterskontrolle für Einkäufe von Produkten, die für Jugendliche nicht geeignet sind. Spiele und Videos ab 18 Jahren, alkoholische Getränke usw. Neben der Tatsache, dass auch mit der SuisseID solche Hürden durch jugendliche Kreativität ohne Probleme umgangen werden können, sei noch erwähnt, dass die Alterskontrolle auch über die Kreditkarte durchgeführt werden könnte.

Das ein Jugendlicher die Kreditkarte seines Vaters mal schnell “entwendet”, das ist jugendliche Kreativität. Das ein Jugendlicher ein Krypto-Verfahren mal so schnell knackt, WOW, dann wäre das ein Top10-Hacker, dessen sechs- bis siebenstelligen Lohn ich gerne hätte. Zudem bräuchte er nebst enorm (!) viel Rechenpower auch mathematische Kenntnisse. Leider verheissen die jüngsten PISA Studien nichts gutes über die Coolnes von Mathe bei Jugendlichen.
Natürlich, das Bewusstsein über die Tragweite einer Weitergabe des PIN Codes einer SuisseID an andere Personen ist in der Bevölkerung bei weitem nicht verankert. Dies ist tatsächlich ein Problem. Aber nicht nur bei der SuisseID sondern generell bei Passwörtern. Z.B. ein vermeintlicher Bluewin Mitarbeiter ruft an und meldet einen geplanten Unterbruch des Internetzugangs an. Er bräuchte schnell das Passwort, damit er die Leitung anschliessend wieder reaktivieren kann.
Wenn man aber die SuisseID künftig z.B. auch für die digitale Steuererklärung, elektronische Abstimmung, dem eBanking und als elektronische Identitätskarte nutzt, da überlegt man sich zwei Mal ob man so schnell den PIN Code jemandem anderen anvertraut. Ich meine, kenne niemanden der seinen PIN Code seiner Bankkarte jemandem anderen anvertraut (ohne ihn wenigstens anschliessend zu ändern).

Gleichzeitig aber würden wir uns – sollte sich denn das behördlich verordnete System durchsetzen – vielen gesellschaftlich äusserst fragwürdigen neuen Möglichkeiten staatlicher Kontrolle aussetzen. Es würde wohl nicht lange dauern, bis die Online-Altersverifikation mittels SuisseID für -zig Produkte obligatorisch erklärt würde.

Im schlimmsten Fall könnte die SuisseID grundsätzlich zur Voraussetzung werden, um überhaupt online gehen zu können.

Da stimme ich voll und ganz zu! Es muss mit Vorsicht genossen werden. Es darf nicht sein, dass der Staat dies als Möglichkeit betrachtet völlige staatliche Kontrolle zu erreichen. Die SuisseID soll nur für ganz gezielte Anwendungen (Abstimmung etc.) Pflicht sein. Die Online-Shops sollten selber bestimmen dürfen, ob sie die SuisseID (oder generell SAML) als zusätzliches Authentisierungsverfahren nutzen möchten.

Mit der SuisseID bauen wir eine digitale Mauer um unser Land, denn für unseren kleinen Markt werden ausländischen Anbieter kaum eine weitere Extrawurst implementieren.

Ich zitiere hier gerne einen User-Kommentar zu einem weiteren SuisseID kritischen Blogeintrag des Autors:

Und das ganze via SAML 2.0. Da ist nichts SuisseID spezifisches dabei was die Schweizer selbst erfunden haben. Das sind offene Standards keine Ricolas.

Nun meine Bitte für das nächste Mal an Herr Gunten: Informieren Sie sich zuerst genau bevor Sie solche Artikel schreiben. Ich stehe, soweit mein Wissen es ermöglicht, auch gerne bei Fragen zur Verfügung.

Category: Security  Tags:  Leave a Comment

Virtual Lab Automation

For the eProcess project, we want to provide easy access to our scenarios to users. A scenario consists usually of multiple hosts, which interact together, and provides different services (such as Service Buses, Applications, WebServices, Identitiy Metasystems, etc.). Users should have the possibility to access those hosts outside our domain and get a feeling of the provided services and how they interact together. They don’t need to provide their own infrastructure and install and configure software, which is very time consuming and usually needs expert knowledge.

Users just can access our infrastructure and configuration in the cloud and use the provided services without wasting time for installation and configuration.

Virtualization

But, what if a scenario consists of three hosts and two users want to access simultaneously the same scenario? This means, that we need to provide six hosts. By more users this means even more hosts.
We need a more flexible approach. Instead of using real (physically dedicated) hosts, we will use virtual hosts (also called virtual machines). Virtual machines are running on a real host (usually a more powerful server), which supports virtualization technology.

VMWare Virtualization

This leads to a better yield of the hardware resources, which reduces the IT costs. When more users want to access a scenario, just more virtual machines will be deployed on the server (without adding more real hosts to the infrastructure).

Virtual Lab Automation

Here comes Virtual Lab Automation (VLA) into play. VLA software is capable of managing virtual machines. Whole scenarios (here: Labs) can be deployed in just few seconds. Network access will be configured automatically and users can easily access the virtual machines through a web interface or a remote desktop connection.

We are using the VMLogix LabManager VLA software. This product can administer different virtualization platforms from different vendors (VMWare, Microsoft, Citrix). It also has an intuitive management web interface and is easy to use. For more detailed information you can watch the VMLogix LabManager Features.

Federated Identity Management

For software developers, working with identity management isn’t a piece of cake. A developer needs to decide which identity technology to use for a particular application. If the application will be accessed in different ways, such as within an organization, across different organizations and via the public internet, one identity technology might not be enough. Next, the developer needs to figure out how to retrieve the identity information (e.g. job title, salary, favorite color etc.) from different locations (directory services, SAP database etc.).

Sounds complex and it is complex. Why not create a single interoperable approach to identity that works in pretty much every situation? Why making the applications hunt for identity information, why not make sure, that this single approach lets users supply each application with the identity information it requires?

Claims-based identity achieves both of these goals. It provides a common way for applications to acquire the identity information they need from the users inside their organization, in other organizations and on the internet. This is making the lives of developers significantly simpler and can also lower the cost of building and manage applications.

Making claims-based identity real requires developers to understand how and why to create claims-based applications. It also requires some infrastructure software that applications can rely on.

We already implemented some claims-based identity test scenarios, where users could single sign-on and use services across organizations. We used for this tests the forthcoming Microsoft Technologies:

  • Active Directory Federation Services 2.0 (formerly known as “Geneva” Server)
  • Windows Identity Foundation (formerly known as “Geneva” Framework)
  • Windows CardSpace (formerly known as Windows CardSpace “Geneva”)

Thanks to supported standards as WS-Trust, WS-Federation and SAML 2.0 in Microsoft “Geneva” (Beta 2), interoperability will be ensured with identity management solutions from other vendors.

References:

Nagios Monitoring

Im Modul ICT Kosten und Beschaffung hatte ich die Aufgabe eine Monitoring-Übung zusammenzustellen.

Das Lernziel bestand darin, dass die Informatik-Studierenden mit dem Monitoring Tool Nagios verschiedene Server und Dienste überwachen sollen. Dazu mussten Sie erst einmal Nagios entsprechend konfigurieren, dass sowohl Überprüfungen auf lokalen sowie auch entfernten Rechnern durchgeführt werden konnten. Für Letzteres wurde der Nagios Remote Plugin Executor (NRPE) eingesetzt. Die Infrastruktur wurde vom hochschulinternen Sun Enterprise Lab zur Verfügung gestellt.

Um zu sehen wie sich Nagios beim Überschreiten von kritischen Werten verhielt, wurden für die Übung Szenarien entwickelt, welche beispielsweise ein System auslasteten oder einen Dienst in die Knie zwangen.

no images were found

Eine genauere Beschreibung zu Nagios und NRPE sowie zur Übung findet man im Übungsdokument und in der Präsentation.
Die Lösungen zur Übung kann ich leider aus didaktischen Gründen nicht aufschalten 😀

Folgende Schritte waren für die Vorbereitung der Übung notwendig:

  • Unterteilung einer globalen Zone von einem Ressource Set in mehrere Solaris Sparse Zonen.
  • Auf jeder Sparse Zone läuft ein bestimmter Dienst (Nagios Monitoring Tool, Apache, MySQL, Fileserver).
  • Installation und Konfiguration der verschiedenen Dienste, NRPE und von Nagios.
  • Erarbeiten geeigneter Szenarien. Bspw. Überprüfung auf korrekte Darstellung einer Webseite, Auslastung des Fileserver und verfügbarer Speicherplatz, Anzahl Einträge einer Datenbanktabelle uvm.

Nagios ist ein gutes und umfangreiches Monitoring Tool. Die Konfiguration von Nagios ins anfangs etwas schwierig, wenn man sich aber etwas eingearbeitet hat erkennt man die ganze Fülle an Konfigurationsmöglichkeiten, welche das Tool noch mächtiger machen.

Category: Monitoring  Tags: ,  Leave a Comment