Chrisi: Eclipse SVN Repo verschlüsseln?

Hi zusammen,

ich suche nach einer Möglichkeit die Daten die im Repository auf dem Projectserver liegen zu verschlüsseln. Ich meine hiermit nicht den Weg vom Client zum Server (SSL), sondern wirklich die Daten die auf dem Server im Repo abgelegt werden.

Gibt es dafür überhaupt eine Möglicheit?

Danke & Viele Grüße
Chrisi

  1. Mahlzeit,

    Gibt es dafür überhaupt eine Möglicheit?

    Aber ja, die gibt es.
    Da diese aber Systemabhängig sind, kann ich dir nicht mehr sagen.

    1. Hi,

      das Repo liegt auf einem Linux Server (Debian Etch).
      Das ganze Dateisystem verschlüsseln wäre natürlich ein Weg, war das auch dein Gedanke?

      Viele Grüße
      Chrisi

      1. Mahlzeit,

        Das ganze Dateisystem verschlüsseln wäre natürlich ein Weg, war das auch dein Gedanke?

        Genau das ist mein Gedanke.

        Der kompliziertere Weg wäre, per Hook-Scripts den Ordner zu Packen und mit Passwort zu versehen, bei einer Anfrage wird das Teil wieder entpackt.
        Das kostet allerdings richtig Zeit und Rechenleistung.

        Es ist ja so, der Zugriff ist ja sowieso geschützt (davon gehe ich aus, wenn es nicht jeder sehen darf). Somit muss jeder, der ans Repo ran will, auf dem Server angemeldet sein, vorzugsweise als Root oder als der SVN-Benutzer.

        Somit macht das alles eh nur bedingt Sinn, da selbts das Ver- und Entschlüsseln dann direkt von diesem Benutzer ausgeführt werden kann.

        Ich sehe also in der ganzen Aktion keinen wirklichen Sinn.

        Wenn du aber mal erklärst, was du genau erreichen willst, gibt es vielleicht andere Lösungen um das Problem anzugehen.

        1. Hi,

          Wenn du aber mal erklärst, was du genau erreichen willst, gibt es vielleicht andere Lösungen um das Problem anzugehen.

          Das Repo soll auf einen vServer, ich möchte mit der Verschlüsselung verhindern das jemand direkten Zugriff auf das Image hat und die Daten klauen kann.

          Bei OpenVZ oder Xen ist es ja nicht wirklich schwer sich als Admin mal das Filesystem der vServer anzuschauen. Mal ganz davon abgesehn das ich nicht der einzige Kunde bin der auf dem Hostsystem liegt - wer weis schon wie der Anbieter z.B. den Dump von einem vServer ablegt oder wie er die Daten sichert.

          VG, Chrisi

          1. Hallo,

            Bei OpenVZ oder Xen ist es ja nicht wirklich schwer sich als Admin mal das Filesystem der vServer anzuschauen. Mal ganz davon abgesehn das ich nicht der einzige Kunde bin der auf dem Hostsystem liegt - wer weis schon wie der Anbieter z.B. den Dump von einem vServer ablegt oder wie er die Daten sichert.

            Das Problem ist: Sobald der Server *selbst* alles verschlüsselt und jemand sich "hardwareseitig" Kontrolle über den Server verschafft (und da das virtualisiert wird ist hardwareseitig halt gleich softwareseitig hier), dann hast Du sowieso verloren.

            Stell Dir vor, das Dateisystem wird komplett verschlüsselt. Dann hast Du jedoch das Problem, das der Schlüssel für das Dateisystem zumindest im RAM des vServers sein muss. Und wenn er automatisch booten soll, muss der Schlüssel auch auf der Platte selbst vorhanden sein, was den Sinn der Verschlüsselung dann wieder kaputtmacht. Und wenn Du den Schlüssel bei jedem Booten eingeben willst, musst Du dennoch eine Möglichkeit haben, während des Bootvorgangs Dich mit dem Rechner zu verbinden und den Schlüssel zu übermitteln - d.h. es muss mindestens ein minimales System mit SSH o.ä. unverschlüsselt vorhanden sein - und das kann ein Angreifer im Zweifel auch manipulieren und dann einen Reboot erzwingen.

            Sobald ein Rechner unter fremder Kontrolle ist, kannst Du ihm grundsätzlich nicht mehr vertrauen.

            Wenn Du daher also nicht willst, dass jemand die Daten auf dem Server abgreifen kann, musst Du sie bereits auf dem Client verschlüsseln - was dann jedoch SVN ziemlich nutzlos macht (im Sinne: Du kannst zwar noch versionieren und so - aber automatisches Mergen / Diffen geht nicht mehr).

            Viele Grüße,
            Christian

            1. Hi,

              danke für eure Antworten.

              Also im Grunde ist dann hier wohl das Stichwort "Hoster der Vertrauens" -  Aber mal ehrlich wem kann man da schon vertrauen? Im Grunde ist am Ende immer jemand da der ein Lücke darstellt, von der Person (Techniker) bis zum Netzwerk (Man in the Middle).

              Die Daten lokal zu verschlüsseln ist für mein SVN zu kompliziert, ich will ja auch noch arbeiten und nicht nur verschlüsseln :-)

              Ich hatte gehoft das ein Addon oder sowas gibt das die Daten automatisch verschlüsselt und dann Committed.

              Ich schätze ich werde meine Daten dann hier in ein lokales SVN stellen und immer nur bei Bedarf den Server hochfahren und ein Commit ausführen.

              VG, Chris

              1. Mahlzeit,

                Also im Grunde ist dann hier wohl das Stichwort "Hoster der Vertrauens"

                Nein, das heisst "Root-Server" mit verschlüsseltem Dateisystem und sicheren Passwörtern.
                Ein vServer istlogischerweise immer unsicherer, wenn du auf die Hardware als einziger Zugriff hast, ist die Gefahr viel kleiner.

                Zusätzlich solltest du einen Hoster nehmen, der möglichst gross ist. Umso grösser die Firma umso weniger interessieren einzelne Kunden.

                1. Moin Moin!

                  Mahlzeit,

                  Also im Grunde ist dann hier wohl das Stichwort "Hoster der Vertrauens"

                  Nein, das heisst "Root-Server" mit verschlüsseltem Dateisystem und sicheren Passwörtern.

                  Und idealerweise nicht beim Hoster, sondern selbst gehostet, im selbst gegrabenen und selbst gegossenen, atombombensicheren Bunker. Ein Studium der ägyptischen Pyramiden empfiehlt sich, um Tarnung, Täuschung, Fallenbau und Abriegelung wertvoller Inhalte zu lernen. Mehrfach geschachtelte faradayische Käfige sollten auch dabei sein. Gut, das ist nicht die billigste Lösung, aber sie ist *SICHER*. ;-)

                  Zusätzlich solltest du einen Hoster nehmen, der möglichst gross ist. Umso grösser die Firma umso weniger interessieren einzelne Kunden.

                  Volle Zustimmung. Das betrifft aber leider auch den Support. Hosting für meinen private Webseites: Ewig lange Reaktionszeiten, Textblöcke, hirnloses Abarbeiten von Ablaufplänen, "Störfaktor Kunde", Null Flexibilität, Kundennummer länger als PI. Hosting für "meinen" Arbeitsserver: Reaktionszeiten je nach Problemdringlichkeit im Minuten- oder Stundenbereich, individuelle, kompetente, freundliche(!) Antworten, Kulanz, selbständiges Mitdenken, auch ungewöhnliche Anforderungen sind kein Problem. Und die Kundennummer hat nur vier Stellen.

                  Alexander

                  --
                  Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                  1. Hallo

                    Also im Grunde ist dann hier wohl das Stichwort "Hoster der Vertrauens"

                    Nein, das heisst "Root-Server" mit verschlüsseltem Dateisystem und sicheren Passwörtern.

                    Und idealerweise nicht beim Hoster, sondern selbst gehostet, im selbst gegrabenen und selbst gegossenen, atombombensicheren Bunker. Ein Studium der ägyptischen Pyramiden empfiehlt sich, um Tarnung, Täuschung, Fallenbau und Abriegelung wertvoller Inhalte zu lernen. Mehrfach geschachtelte faradayische Käfige sollten auch dabei sein. Gut, das ist nicht die billigste Lösung, aber sie ist *SICHER*. ;-)

                    Ägyptische Pyramiden im selben Satz wie der Schlüsselbegriff "sicher"? Gewagt, gewagt! ;-)

                    ... Kundennummer länger als PI.

                    *hehe*

                    Tschö, Auge

                    --
                    Die deutschen Interessen werden am Liechtenstein verteidigt.
                    Veranstaltungsdatenbank Vdb 0.2
                  2. Hi,

                    Ein Studium der ägyptischen Pyramiden [...] Mehrfach geschachtelte faradayische Käfige

                    In dem Zusammenhang wohl eher pharaonische Käfige ;-)

                    cu,
                    Andreas

                    --
                    Warum nennt sich Andreas hier MudGuard?
                    O o ostern ...
                    Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
          2. Moin!

            Wenn du aber mal erklärst, was du genau erreichen willst, gibt es vielleicht andere Lösungen um das Problem anzugehen.

            Das Repo soll auf einen vServer, ich möchte mit der Verschlüsselung verhindern das jemand direkten Zugriff auf das Image hat und die Daten klauen kann.

            Solange der Server läuft, und das Betriebssystem Zugriff auf die unverschlüsselten Rohdaten erlaubt (selbst wenn sie verschlüsselt auf der Platte liegen), solange kann man angreifen und die Dateien auslesen. Denn die Tatsache, dass verschlüsselt wird, steht ja nachlesbar im RAM durch Anwesenheit entsprechender Software, und der zu benutzende Schlüssel steckt ebenfalls im RAM.

            Deshalb dürfte es bei einem vServer extrem schwierig werden, dort etwas geheim halten zu wollen - zumindest gegenüber dem Betreiber des Servers.

            Bei OpenVZ oder Xen ist es ja nicht wirklich schwer sich als Admin mal das Filesystem der vServer anzuschauen. Mal ganz davon abgesehn das ich nicht der einzige Kunde bin der auf dem Hostsystem liegt - wer weis schon wie der Anbieter z.B. den Dump von einem vServer ablegt oder wie er die Daten sichert.

            Wenn du den Administratoren deines Providers nicht vertraust, dann hoste dort, wo du den Admins vertraust. Denn es gibt tausend Wege, dass man an den Inhalt der Dateien rankommt. Der Provider kann ja einfach an der Leitung lauschen (auch "hinter" der Ansatzstelle für SSL), er kann sämtliche deiner Tastatureingaben (für das Verschlüsselungspasswort) abfangen, er kann dir ein beliebig manipuliertes Serverimage zur Nutzung unterschieben, von dessen Vorhandensein du absolut nichts bemerkst. Nichts ist sicher. Dagegen hilft nur, dass du ausschließlich verschlüsselte Daten in das SVN spielst. Dann wiederum wird's schwieriger mit der gemeinsamen Arbeit, und außerdem wäre es in so einem Fall vermutlich deutlich einfacher, das Repository einfach zuhause zu hosten, und nicht auf dem Server.

            - Sven Rautenberg

  2. Moin!

    ich suche nach einer Möglichkeit die Daten die im Repository auf dem Projectserver liegen zu verschlüsseln. Ich meine hiermit nicht den Weg vom Client zum Server (SSL), sondern wirklich die Daten die auf dem Server im Repo abgelegt werden.

    Wem willst du mit dieser Maßnahme den Zugriff verwehren?

    Klingt so, als solltest du deine Datei lokal verschlüsseln und erst dann ins SVN spielen. Damit verschenkst du allerdings den kompletten Vorteil von SVN - von der Zuordnung einer Changeset-Nummer und der Abrufbarkeit früherer Versionen mal abgesehen.

    - Sven Rautenberg

    1. Hi,

      Wem willst du mit dieser Maßnahme den Zugriff verwehren?

      Allen Personen die unter Umständen Physikalischen Zugriff auf den Hostserver haben oder mit Adminrechten auf das Hostsystem ausgestattet sind (ich nutze einen vServer).

      Ich schätze sinnvoll wäre es das Dateisystem zu verschlüsseln, oder ein neues Image im vServer anzulegen, dieses zu verschlüsseln und dann zu mounten und die Daten des SVN dort zu hinterlegen.

      VG, Chrisi

      1. Moin!

        Wem willst du mit dieser Maßnahme den Zugriff verwehren?

        Allen Personen die unter Umständen Physikalischen Zugriff auf den Hostserver haben oder mit Adminrechten auf das Hostsystem ausgestattet sind (ich nutze einen vServer).

        Ich schätze sinnvoll wäre es das Dateisystem zu verschlüsseln, oder ein neues Image im vServer anzulegen, dieses zu verschlüsseln und dann zu mounten und die Daten des SVN dort zu hinterlegen.

        Nein. Alle Maßnahmen, die Sicherheit erst auf diesem Server produzieren, sind von den Admins einseh- und umgehbar.

        Das Dateisystem verschlüsselt zu halten hilft nur, wenn der Server nicht automatisch booten kann, d.h. du zum Boot das Passwort eingeben musst, und wenn sichergestellt ist, dass im laufenden Betrieb niemand den RAM-Speicher kopieren oder über den Verschlüsselungstreiber auf die Festplatte zugreifen kann. Beides kannst du nicht garantieren, wenn die Hardware in fremden Händen ist.

        - Sven Rautenberg

      2. Mahlzeit,

        oder ein neues Image im vServer anzulegen, dieses zu verschlüsseln und dann zu mounten und die Daten des SVN dort zu hinterlegen.

        Das macht aber nur Sinn, wenn das Image immer nur dann gemountet wird, wenn Daten angefordert oder geschrieben werde. Zusätzlich darf es keine Möglichkeit geben, vom Server direkt das Image zu monuten und zu entschlüsseln.

        Da der letzte Punkt völlig unmöglich ist, fällt diese Lösung ebenfalls aus.

        Wie ich geschrieben habe, ist die maximal mögliche Sicherheit ein Rootserver auf dessen Hardware du als einziger Zugriff hast. Also musst du das Login per SSH für möglichst jeden verbieten, z.B. per RSH-Key und der Sperrung eines Passwortlogin.
        Trotzdem kann sich jemand zwischen dich und den Server hängen.

        Was dir evtl. noch helfen würde, ist ein Server zuhause und eine DSL-Flat.
        Das Ganze dann entweder per Dyn-DNS , oder besser, du kannst die aktuelle IP irgendwo ablesen, wobei diese Seite per Passwort und SSL geschützt ist.

        Dann noch ein VPN mit SSL-Tunnel, dann hat du wohl die grösstmögliche Sicherheit.

        Allerdings sind wir in einem Bereich, wo die Grenze zur Paranoia bereits überschritten scheint. Wenn deine SOftware wirklich so wertvoll ist, dass solche Aktionen nötig sind, hat die auf einen VServer eh nix verloren. Dann gehört die auf einen Rechner, der in einer Abschirmkammer sitzt, sonst kann ich per einfacher Antenne im Umkreis von 50 Metern den Bildschirminhalt deines Rechners sichtbar machen.
        Und wenn sie nicht so wertvoll ist, interessiert sich eh niemand dafür, so dass die ganze Aktion ziemlich fürn Arsch ist.