Username + Passwort + X

Internet Internet Sicherheit
1

Liebe Experten,

ich möchte mich durch das Internet von jedem beliebigem Rechner aus an meinen Server anmelden können und von dort aus auf bestimmte Daten einer .NET Anwendung zugreifen. Da mir unbekannt ist, ob der fremde Rechner, von dem aus ich auf meine Daten zugreife einen Keylogger, o.ä. laufen hat, denke ich über zusätzliche Sicherungsmechanismen wie z.Bsp. Secure-ID oder ein USB-Dongle nach. Soweit ich weiss, besteht das Problem bei den USB-Dongles ( eToken ) darin, dass dafür ein Treiber installiert werden muß. Welche Lösungsvorschläge habt Ihr ?

Besten Dank und Gruß,
speedofthoughts

2

Hallo,

ich möchte mich durch das Internet von jedem beliebigem
Rechner aus an meinen Server anmelden können und von dort aus
auf bestimmte Daten einer .NET Anwendung zugreifen.

Autsch.
Geht es nur um die Daten oder um ne komplette Applikation. DANN würde ich nämlich zusätzlich Citrix vorschlagen.

ein Treiber installiert werden muß. Welche Lösungsvorschläge
habt Ihr ?

Also für „einigermassen“ Sicher halte ich den RSA Key eben mit einer SecurID Card. Ist halt etwas aufwendiger das alles für eine (!) Anwendung zu implementieren…

Gruß
h.

3

Also für „einigermassen“ Sicher halte ich den RSA Key eben mit
einer SecurID Card. Ist halt etwas aufwendiger das alles für
eine (!) Anwendung zu implementieren…

Naja, aber für 'ne Card braucht er halt wieder einen Card-Reader. Und den muss er ja erst mal wieder installieren. Und in dem Webcafe, in dem er selbst installieren darf, darf er nicht ins Netz, weil dort auf den Rechnern die Trojaner und Keylogger auf ihn lauern wie die Zecken auf den Warmblüter.

Ich hab mir zu diesem Thema auch schon meine Gedanken gemacht, und bin zu dem Schluss gekommen, dass ich im Urlaub halt das ganze Programm mitschleppen muss: Laptop, ausgestattet mit analogem und ISDN-Anschluss bzw. Karten, internationaler Steckeradaptersatz. Und in der Firma einen Linux-Server, über den ich via ssh auf die Windows-Kisten tunneln kann, alternativ Openssh direkt auf dem fernzusteuernden Win-Rechner. Entspr. NAT-Einträge in der Firewall.

Gruss,
Schorsch

4

Also für „einigermassen“ Sicher halte ich den RSA Key eben mit
einer SecurID Card. Ist halt etwas aufwendiger das alles für
eine (!) Anwendung zu implementieren…

Naja, aber für 'ne Card braucht er halt wieder einen
Card-Reader.

Öh, Schorsch, du hast noch nicht wirklich mit SecurID gearbeitet, oder? Die Karte oder das Token stellen einfach nur über ein LCD eine alle zwei Minuten wechselnde Ziffer dar, die man dann händisch in eine Anmeldemaske überträgt. Da muss nichts an Hard- oder Software am Client installiert werden. Wir hatten die Dinger in meiner letzten Firma gekoppelt mit einer Single-Sign-On Lösung, und es war einfach klasse. Über Citrix, oder notfalls auch NView direkt im Browser auf alle Applikationen zugreifen können. Für den schnellen Mailabruf dann noch OWA, und selbst die Testumgebung für Kundenprojekte und Messepräsentationen alles identisch geschützt und von überall notfalls ausschließlich über Browser erreichbar (wobei ein CITRIX-Client die Sache natürlich komfortabler macht).

Gruß vom Wiz

5

Öh, Schorsch, du hast noch nicht wirklich mit SecurID
gearbeitet, oder?

Ne, hab ich tatsächlich noch nicht, das habe ich mit einer normalen Scheckkartenlösung verwechselt. Ich habe mir das aber gleich mal angeschaut. Was mir dabei noch fehlt: Wenn ich’s richtig sehe, habe ich mich mittels SecurID gegenüber dem RSA-Server eindeutig authorisiert, ich habe aber noch keine verschlüsselte Verbindung. Sobald ich also sonstige anwendungs- oder systemspezifische Kennwörter des Firmennetzes eingebe, gehen diese wieder offen über die Leitung bzw. direkt an den Keylogger.

Einem evtl. Hacker ist also zunächst ein hohes Hindernis gesetzt, er kann aber, zumindest wenn ich vom Webcafe aus ein Netzwerk administrieren möchte, jede Menge Informationen über Interna gewinnen, die ich nicht preisgeben möchte. Somit bleibt, zumindest für anspruchsvolle Aufgaben, doch wieder nur der Weg über den eigenen Schlepptop.

Gruss,
Schorsch

6

Wenn ich’s
richtig sehe, habe ich mich mittels SecurID gegenüber dem
RSA-Server eindeutig authorisiert, ich habe aber noch keine
verschlüsselte Verbindung. Sobald ich also sonstige
anwendungs- oder systemspezifische Kennwörter des Firmennetzes
eingebe, gehen diese wieder offen über die Leitung bzw. direkt
an den Keylogger.

Kommt ganz drauf an, du kannst die RSA-Geschichte ja mit einer Single-Sign-On-Lösung verbinden. Dann brauchst du ja überhaupt keine Passwörter mehr zusätzlich zu dem per Token abgesichterten Anmeldevorgang. Nach abgesicherter Anmeldung am System übernimmt dann die Single-Sign-On-Lösung auf dem Server die Authentifizierung gegenüber den weiteren Systemen. Dies entsprechend sicher und ohne, dass irgendwelche Anmeldedaten über die Internetverbindung gehen.

Wenn du jetzt zusätzlich die gesamte Verbindung verschlüsseln willst, kannst du natürlich auch dies erreichen, indem du nach Anmeldung per SecurID automatisch eine verschlüsselte Verbindung aufbauen lässt (Soll sogar in der Form funktionieren, dass als Key wiederum ein RSA-Code verwendet wird, habe mich hiermit selbst aber nie beschäftigt, müsstest du mal selbst forschen).

Man kann die Sache also schon ganz schön durch RSA SecurID, insbesondere in Verbindung mit einer Signle-Sign-On-Lösung, absichern und dabei gleichzeitig sogar noch Komfort und zusätzliche Sicherheit auch im internen Einsatz gewinnen. Dann ist Schluss mit der „privaten“ Weitergabe einzelner Passwörter und auch die Administration der Passwörter kann man dann mit einem einheitlichen Rollen- und Rechtekonzeot gleich noch perfektionieren.

Gruß vom Wiz

1 „Gefällt mir“
7

Kommt ganz drauf an, du kannst die RSA-Geschichte ja mit einer
Single-Sign-On-Lösung verbinden. Dann brauchst du ja überhaupt
keine Passwörter mehr zusätzlich zu dem per Token
abgesichterten Anmeldevorgang.

Das ist, zumindest in meinen Ohren, zwar Sphären-, aber Zukunftsmusik. Voraussetzung für eine Single-Sign-On Lösung ist ein einigermassen homogenes System, in dem alle Teilsysteme ihre Berechtigungsdaten von einem Server holen. Sowas ist mittels ldap sicherlich machbar, nicht aber in einem heterogenen System, wie ich es verwalte. Zwar wachsen hier auch langsam die früher sich völlig fremd gegenüberstehenden Teilsysteme zusammen, wir setzen aber nach wie vor Produkte mit den verschiedensten Authentifizierungsmethoden ein. Und ein System, das in zwei Jahrzehnten aus den verschiedensten Wurzeln zu einem Stamm zusammengewachsen ist, stellt man nicht so leicht über Nacht um.

Wenn ich natürlich z. B. an einem fernen Standort Büros völlig neu einrichte, dann ist das mit Sicherheit eine Option.

Wenn du jetzt zusätzlich die gesamte Verbindung verschlüsseln
willst, kannst du natürlich auch dies erreichen, indem du nach
Anmeldung per SecurID automatisch eine verschlüsselte
Verbindung aufbauen lässt (Soll sogar in der Form
funktionieren, dass als Key wiederum ein RSA-Code verwendet
wird, habe mich hiermit selbst aber nie beschäftigt, müsstest
du mal selbst forschen).

In diesem Fall benötigst du aber wieder auf der Clientseite entspr. Verschlüsselungs-Hard- oder Software, die erst mal installiert oder angeschlossen sein will. Aber das Thema ist auf jeden Fall hochinteressant.

Gruss,
Schorsch

8

Das ist, zumindest in meinen Ohren, zwar Sphären-, aber
Zukunftsmusik. Voraussetzung für eine Single-Sign-On Lösung
ist ein einigermassen homogenes System, in dem alle
Teilsysteme ihre Berechtigungsdaten von einem Server holen.
Sowas ist mittels ldap sicherlich machbar, nicht aber in einem
heterogenen System, wie ich es verwalte.

Würde ich nicht sagen, genau zu diesem Zweck gibt es doch die diversen professionellen großen Single-Sign-On-Lösungen. Habe mich selbst in der letzten Firma damit zwar nicht beschäftigt, weiß aber, dass wir da bei einigen Unternehmen Projekte zum Thema hatten und auch erfolgreich abgeschlossen haben. Ich würde mich da wirklich mal schlau machen, denn die Vorteile eines einheitlichen Rolle- und Rechtekonzepts überwiegen sicher die einmaligen Kosten bei Weitem.

Und wenn ich mir ansehen, wieviel Applikationen z.B. schon alleine heute in der Lage sind, den ADS von W2K zur Authentifizierung zu nutzen, oder eben LDAP, oder NDS oder Vines, … Da kann man oft viele Fliegen mit einer Klappe schlagen und muss sich dann nur noch um wenige Exoten kümmern.

Gruß vom Wiz

1 „Gefällt mir“
9

Und wenn ich mir ansehen, wieviel Applikationen z.B. schon
alleine heute in der Lage sind, den ADS von W2K zur
Authentifizierung zu nutzen, oder eben LDAP, oder NDS oder
Vines, … Da kann man oft viele Fliegen mit einer Klappe
schlagen und muss sich dann nur noch um wenige Exoten kümmern.

Hallo Wiz,

am Donnerstag ersetzen wir unser zentrales Datenbanksystem, eine AS400 (oder neu-IBM-sprachlich: iSeries) durch ein neues Modell mit endlich mal aktuellem Releasestand (zurzeit hinken wir noch 5 Jahre hinterher). Dieses Modell unterstützt LDAP, zumndest für die wesentlichen Anwendungen im Verwaltungsbereich könnten wir eine zentrale Benutzerdatenbank über w2k und AS400 spannen. In der Produktion geht’s schon nicht mehr, weil die dort eingesetzte QM-Software nicht LDAP-fähig ist. Aber das ist kein Exot, sondern eine überaus unternehmenskritische Anwendung.

Als wir das alte QM-System ersetzt haben (wegen mangelnder-Y2K Tauglichkeit), war das ein Prozess von der Planung bis zur Inbetriebnahme von über einem Jahr. Und dieser Art setzen wir diverse Produkte ein - einige, die durchaus State of the art, aber dennoch nicht Single-Sign-On-fähig sind, einige, gegen deren Anschaffung ich mit Händen und Füssen vergebens gestrampelt habe weil sie zum Zeitpunkt der Anschaffung m. E. schon Dinos waren. Da setzt du nicht eben mal ein einheitliches Rollen- und Rechtekonzept drüber.

Für ein solches benötigst du eine einigermassen homogene Softwarelandschaft, Standardprodukte von wenigen ausgesuchten Herstellern. Aber diese Homogenität zu schaffen setzt voraus, dass diese Standardprodukte überhaupt auf dem Markt sind. Und das ist unter den speziellen Bedingungen meines Arbeitgebers leider vielfältig nicht der Fall.

Ein wirkliches Argument gegen deine Thesen ist das allerdings nicht, da Rechte im Produktionsbereich wesentlich arbeitsplatzabhängig sind und die sicherheitskritischen Bereiche kaum berühren. Dies sieht z. B. in der FiBu oder LoBu ganz anders aus. Und da kann man über eine zentrale Rechtevergabe tatsächlich viel erreichen.

Auch wenn wir vom ursprünglichen Thema weit abgewichen sind, die Diskussion hat mir einige Anregungen gebracht. Die User, die beim lesen dieses Beitrags geschrieen haben ne, nich schon wieder der Schorsch, wird doch echt langweilig mögen mir daher diese Störung ihrer Gemütsruhe verzeihen.

Gruss,
Schorsch