Dokumentation von Kundennetzen
-
Hallo,
ich schaue mir gerade i-doit für die Dokumentation von Kundennetzen an. Ursprüngliche Idee war, das auf einem Linux-Server bei einem Hoster zu installieren (Mandantenversion). Dann hätten auch interne Supporter beim Kunden Zugriff, oder vielleicht Sekretariate zur Pflege von Buchhaltungsdaten (soweit es technikaffine Sekretariate sind, aber das gibt's ja auch).
Jetzt sind mir Bedenken hinsichtlich der Sicherheit gekommen: Da sind ja doch sehr sensible technische Informationen hinterlegt. Von Passworten mal ganz abgesehen. So etwas möchte ich nicht über ein Webinterface erreichbar haben… doch, eigentlich möchte ich das schon, aber habe halt Bauchschmerzen.
Deshalb Frage: Macht das jemand? Mit zusätzlicher Absicherung oder wirklich nur mit dem i-doit-Passwort gesichert?
Viele Grüße,
Oliver -
Idee: Einfach eine HTTP BASIC AUTH davor schalten? (.htaccess)
Das ist nach aktuellem Technologiestand relativ sicher.Das Passwort ließe sich zudem unabhängig von i-doit-Credentials verwalten und auch für mehrere User einrichten. Und für die sichere Datenübertragung könnte man SSL zuschalten.
-
Hm, ja, diese Absicherung wäre vielleicht eine Möglichkeit. Allerdings kann ich als absoluter Linux-Laie nicht beurteilen, inwieweit damit der Server insgesamt abgesichert wäre… eigentlich doch nur der http/https-Zugriff, oder? Und die Verwendung von zwei Passworten ist unschön, zudem können die Benutzer diese nicht selber ändern. Aber vielleicht schalte ich diesen Schutz noch davor.
Ich beschreibe mal das Problem ausführlicher: Wir setzen selber keine Linux-Webserver auf oder ein, aber nach unserem Eindruck werden solche Systeme, die von unseren kleineren Kunden meist bei der Webagentur gemietet werden, oft erfolgreich angegriffen. Die Quote scheint mir da tatsächlich ziemlich hoch, weil die Agenturen das oft unterschätzen oder CMS wie typo3 dann nicht regelmäßig aktualisiert werden usw. Uns selber fehlt hier das Know-how, aber man muss auch einfach bedenken: Wenn wir Kundennetze dokumentieren und sogar die Passworte hinterlegen, dann wäre ein erfolgreicher Angriff auf unsere i-doit-CMDB (Abfluss der Files, Abfluss der Datenbank) ein absoluter GAU, weil damit sämtliche Kundennetze im Grunde offen stünden. Buchhaltungsdaten, Strukturen, Administrationspasswörter usw. Damit wären wir wohl weg vom Markt, und der eine oder andere Kunde auch.
Vor diesem Hintergrund brauchen wir eine Sicherheit, welche alle realistischen "Fallen" umfasst, die ja vielleicht erst in Zukunft auftauchen, und die wir auch ohne große Linux-Kenntnisse selber einschätzen können. Und da bin ich inzwischen soweit, dass ich mir nur dieses Nutzungsszenario vorstellen kann:
Einen Linux-vServer bei einem Provider anmieten, auf welchem die lokale Firewall (in der Regel wohl iptables?) keine ausgehenden Verbindungen außer DNS-Auflösung und SMTP (i-doit-Meldungsversand) zulässt, und eingehende Verbindungen ausschließlich per SSH 22 (von unserer IP) und per https 443 (nur von ausgewählten IPs und/oder MACs, nämlich von selektierten Kunden bzw. deren Mitarbeitern oder sogar deren externen Dienstleistern).
Mir wäre nicht bekannt, dass es schon erfolgreiche Angriffe zwischen virtualisierten Systemen gibt, auch wenn es da wohl schon Ansätze gibt. Netzwerktechnisch würde das ja nicht gehen, weil die Firewall lokal auf der Maschine läuft, ein Angreifer im gleichen LAN wie unser vServer kommt also auch nicht rein. Dass den Hostern komplette virtuelle Server entwendet werden, habe ich noch nicht gehört. Bliebe ein Angriff direkt vom Rechner eines Kunden auf den Webserver. Dagegen würde wir den Linux-/Apache/i-doit-Stand aktuell halten.
Eine Möglichkeit, Benutzerkonten in i-doit bei Brute force zu sperren, gibt es wohl nicht... das ist schade und eine ziemliche Sicherheitslücke, gemessen an den Daten, die man da reinspeichert. Bestimmte Systeme sichert man besser ab als andere, aber da wäre es vielleicht sinnvoll, dieses dann nicht in die CMDB aufzunehmen. Aber das ist nicht Sinn einer CMDB... Jedenfalls ist es Quatsch, dass Microsoft, Cisco & Co. nach ein paar falschen Loginversuchen sperren können, wenn man bei der CMDB so oft probieren kann, wie man möchte, um am Ende auf der Autobahn an anderen Schutzmechanismen vorbeizufahren.
Jedenfalls würden mich Meinungen zu dem Thema sehr interessieren!
-
Einen Linux-Server, egal ob nun virtuell oder dediziert, kann man durchaus sehr sicher machen. Ich würde keinen vServer nehmen, da die CMDB durchaus sehr ressourcenintensiv werden kann (vor allem bei mehreren Mandanten in nicht quantifizierter Größe). Du willst genug Ressourcen übrig haben.
Wenn Sicherheit das zentrale Thema ist (davon gehe ich nach Deinen bisherigen Angaben aus), würde ich das um eine Firewall/VPN-Lösung erweitern und ansonsten von "außen" gar keine Zugriffe oder eben nur per bereits angesprochener HTTP-BASIC-AUTH erlauben. Die läßt sich einfach einrichten und ist, da sie direkt im Apache stattfindet, nahezu unknackbar - zumindest wenn das Passwort vernünftig gewählt ist. Übrigens kann man über den Weg auch statische Kundennetze (oder eben VPN-IP-Ranges) freischalten und andere außen vor lassen. Dann findet für die "richtigen" Nutzer natürlich auch keine 2. Passwortabfrage statt, sondern nur für Leute, die von unbekannten IP-Ranges darauf zugreifen. Die sicherste Lösung ist aber die "reine" VPN-Variante, d.h. andere externe Zugriffe sind nicht möglich. Nur, wer im VPN sitzt, kann auf die CMDB zugreifen. Ist im Prinzip wie ein Firmennetz, und kann auch mit solchen kombiniert werden.
Zufällig sind wir übrigens ISP, und haben solche VPN-Installationen schon mehrfach (auch für prominente Kunden) im Einsatz. Ich mag hier auf dem Board keine öffentliche Werbung machen, aber wenn Du Interesse hast und Unterstützung brauchst, kannst Du dich per PN an mich wenden.
Gruß,
Frank