Sicherheit von Repositories

[prolemiker]

Ich betrachte meine Repositories als "sicher" und "vertraulich", schliesslich sind sie strikt zugriffsbeschränkt (MFA und auditing etc) und beinhalten selbstverständlich vertrauliche Geschäftsgeheimnisse.

In meinen Augen ist es dann in Ordnung, dort auch z.B. Zugangsdaten zu speichern. Es ist mir um Welten lieber, wenn ich im Repository ein `production.json` liegen habe, als irgendwie im Web-Interface das als ENV für den CD zu konfigurieren - intransparent und vendor-locking. Oder noch schlimmer - die Entwickler zu zwingen, `production.json` durch ihre Maschienen zu kopieren und händisch einzufügen, wo es auch immer gebraucht wird.

Wenn jemand öffentliche Repositories verwendet, obwohl es um vertrauliche Daten geht, ist das Problem ein ganz anderes als dass da sie dort auch Zugangscodes drinstehen haben.

[Kein Kostverächter]

Das ist aber blauäugig. Gerade wenn diese Zugangsdaten Zugriff auf personenbezogene Daten Dritter (Kundendaten) bieten, kann man diese nicht bei Drittanbietern ablegen, auf deren Sicherheitsmaßnahmen mal selber keine Einfluss hat.
Bin kein Anwalt, aber das wäre im Schadensfall zumindest schon mal fahrlässiger Umgang mit Kundendaten, wo dann bei der DSGVO schnell der obere Bereich des Strafmaßes zur Anwendung kommt. Vor allem, wenn diese Tatsache nicht in der Datenschutzerklärung bzw. der Datenverarbeitungsvereinbarung erwähnt ist.

Bis die Tage,

KK

----------------------------------------------------------
Mach dir deine eigenen Götter, und unterlasse es, dich mit einer schnöden Religion zu beflecken.
(Epikur, griech. Phil., 341-270 v.Chr.)
----------------------------------------------------------
We provide AI Blockchain Cloud (ABC) enabled applications bringing Enterprise level synergies to vertically integrated business processes.

[HeroFeat]

Das scheint mir nicht sehr geschickt.

Ein "Problem" ist ja auch das ein Repository (wenigstens bei git) nicht mal so eben mal vergisst (ist ja der Zweck). Das heißt man bekommt Zugangsdaten die einmal darin gelandet sind nicht mehr wirklich heraus.
Wenn dann also deine production.json später einmal gelöscht wird und dann noch etwas später doch einer etwas breiteren Gruppe Zugriff gegeben werden soll lauert in der Historie eine ziemliche Miene.

Einfach gleich sauber arbeiten und Credentials auslagern. Das kann ja auch ein repo irgendeiner Art sein, aber Code und Credentials sollten nicht in einem Repo sein.

[prolemiker]

Kein Kostverächter schrieb:
--------------------------------------------------------------------------------
> Das ist aber blauäugig. Gerade wenn diese Zugangsdaten Zugriff auf
> personenbezogene Daten Dritter (Kundendaten) bieten, kann man diese nicht
> bei Drittanbietern ablegen, auf deren Sicherheitsmaßnahmen mal selber keine
> Einfluss hat.

Ja, Git ist self-hosted. Eigene Domain und eigenes Zertifikat sind recht wichtig, auch um Verwechselungen auszuschliessen (weiss nicht, ob die Grossen sowas anbieten wenn man nicht das Self-Hosting Packet nimmt?) und teilweise auch VPN. Datenbanken (deren Zugriffsdaten im git liegen bzw. deren Konfiguration dort versioniert wird) sind natürlich auch nochmals IP-Whitelisted, so dass sie nur von bestimmten Netzen aus erreichbar sind (ist jetzt nicht die grösste Sicherheit, aber hilft doch ein wenig, wie ich finde).

[prolemiker]

HeroFeat schrieb:
--------------------------------------------------------------------------------
> Das scheint mir nicht sehr geschickt.
>
> Ein "Problem" ist ja auch das ein Repository (wenigstens bei git) nicht mal
> so eben mal vergisst (ist ja der Zweck). Das heißt man bekommt Zugangsdaten
> die einmal darin gelandet sind nicht mehr wirklich heraus.
> Wenn dann also deine production.json später einmal gelöscht wird und dann
> noch etwas später doch einer etwas breiteren Gruppe Zugriff gegeben werden
> soll lauert in der Historie eine ziemliche Miene.

Verstehe ich nicht. Wenn Mitarbeiter, die Zugriff hatten, die Firma verlassen, werden die Credentials geändert - das sollte ja so oder so passieren.
Du meinst, die Gefahr ist, dass man die Credentials aus dem git löscht, und dann später jemand, dem man mit seinen Geschäftsgeheimnissen vertraut (d.h. Zugriff auf dies Repo gibt), die dort herausfischt, weil man die Person nicht hätte mit den Credentials vertrauen dürfen? Und man die Credentials auch noch nicht geändert hat, obwohl aus dem git gelöscht?

> Einfach gleich sauber arbeiten und Credentials auslagern. Das kann ja auch
> ein repo irgendeiner Art sein, aber Code und Credentials sollten nicht in
> einem Repo sein.
Ich hatte heimlich gehofft, hier eine Diskussion anzustossen und darum einwenig trollig begonnen. Also super, ich lese gespannt, wie Du sauber arbeitest:
- Wohin lagerst Du die Credentials aus?
- Wodurch ist dieser Ort sicherer als das entsprechende Repository?
- Falls es nur ein anderes (git) Repo ist, verstehe ich Deine ganze Argumentation nicht (und geht am Ende wieder darauf zurück, dass wenn falsche Leute auf eine Repo zugriff haben das das eigentlich Problem ist)
- Wie versionierst Du derlei kritische Informationen?

[tatiplut]

Ist der Kreis derer mit Zugang zum entsprechenden Repository identisch mit denen, die zum Zugriff auf die Produktionsumgebung und -daten Zugriff brauchen?

Falls Ja und das auch immer so bleibt dann sehe ich hier auch wenige Risiken.
Wenn aber auch mal ein Kollege aus einer anderen Abteilung oder ein Consultant oder Auditor oder ... Lesezugriff auf das Repo bekommt hat man unnötige Probleme.


Neben Menschen sollte man dabei natürlich auch Tools verschiedener Art berücksichtigen.
Ein Tool für die Analyse von Quellcode braucht keine Zugangsdaten.


Außerdem ist der Schutzbedarf einfach ein anderer. Wenn ein Konkurrent den Quellcode lesen kann, schränken ihn rechtliche Hürden doch recht stark bei der Verwendung ein. (Sonst könnte es ja auch keine erfolgreichen Open-Source Geschäftsmodelle geben)
Ein Krimineller mit Zugang zu Kundendaten (oder Zugangsdaten des Zahlungsdienstleisters oder VM-Buchungs-Zugangsdaten oder ...) fühlt sich durch rechtliche Hürden meistens nicht sonderlich beschränkt und wird dementsprechend tendenziell mehr Schaden anrichten können.

[ashahaghdsa]

Na ja, Lesezugriff auf den Code kann man sehr weitreichend verteilen. Schreibzugriff eingeschränkter. Zugangsdaten muss niemand wirklich zu gesicht bekommen. Wenn die in nem eigenen Repo liegen, muss da nicht jeder Entwickler drauf zugriff haben.

Klar kann jeder, der Code einschleusen kann, auch die Zugangsdaten extrahieren. Wenn das aber nur übers Code-repo geht, ist das wenigstens gut kontrollierbar.

Ich hab mit sowas in der Praxis nix zu tun. Aber scheint mir doch sinnig, die Zugangsdaten in ein extra Repository zu legen, auf dass dann nur die Server zugriff haben.?

[prolemiker]

tatiplut schrieb:
--------------------------------------------------------------------------------
> Wenn aber auch mal ein Kollege aus einer anderen Abteilung oder ein
> Consultant oder Auditor oder ... Lesezugriff auf das Repo bekommt hat man
> unnötige Probleme.
Das ist ein wirklich guter Punkt

> Neben Menschen sollte man dabei natürlich auch Tools verschiedener Art
> berücksichtigen.
> Ein Tool für die Analyse von Quellcode braucht keine Zugangsdaten.
Die laufen aber hoffentlich alle vollständig unter meiner Kontrolle und isoliert. Aber ja, auch das ist ein ganz gutes Argument

> Außerdem ist der Schutzbedarf einfach ein anderer. Wenn ein Konkurrent den
Im Prinzip ja, aber eher vernachlässigbar denke ich. Wenn jemand unbefugt an meine Daten kommt, ist es so oder so schlimm.

Du hast ziemlich gute Argumente gegeben, darum bin ich auch bei Dir gespannt, was Du zur Lösung vorschlägst.
- submodule mit credentials, striktere Zugriffskontrolle?
- environment variablen im Web Interface vom Git Server?
- Implizit (CD server zieht das repo und hält selbst die credentials fürs deployment)?

[jankapunkt]

Also wir haben im repo unsere dev settings und per default alle deployment folder im gitignore schon bei dem anlegen eines neuen Repos (dank templates).

Deployment files werden auch nicht über irgendein web-interface verwaltet sondern nur in json files bearbeitet und von unserem CD server eingebungen.

Wir trennen dabei die ci vom cd, auch wenn da einige puristen gleich wieder rotieren werden, aber der public Teil der CI bleibt bei GitHub aber alles was mit privaten keys usw. zu tun hat bleibt strikt bei uns.

[prolemiker]

jankapunkt schrieb:
--------------------------------------------------------------------------------
> Also wir haben im repo unsere dev settings und per default alle deployment
> folder im gitignore schon bei dem anlegen eines neuen Repos (dank
> templates).
>
> Deployment files werden auch nicht über irgendein web-interface verwaltet
> sondern nur in json files bearbeitet und von unserem CD server
> eingebungen.
>
Klingt vernünftig, aber wie managed / versioniert ihr die deployment files?

Bin ein wenig versucht, alle Credentials über Environment Variablen zu implementieren, das scheint jetzt (wieder?) modern zu sein und macht sich mit Docker, Docker-im-docker etc, fast angenehmer. Aber auch hier ist wieder die Frage, wo stehen die Credentials zentral? Im Passwort-manager? In unversionierten Dateien, die man mit scp umherschiebt (bzw der CD server umherschiebt und notfalls aus einem Backup des CD servers wiederhergestellt werden müssen)?

[tatiplut]

prolemiker schrieb:
--------------------------------------------------------------------------------
> Du hast ziemlich gute Argumente gegeben, darum bin ich auch bei Dir
> gespannt, was Du zur Lösung vorschlägst.
> - submodule mit credentials, striktere Zugriffskontrolle?
Klingt interessant, könnte mir aber vorstellen, dass das nervig ist wenn man dann bei einem "git submodule update" Berechtigungsfehler bekommt. Wäre vielleicht mal einen Versuch wert.

> - environment variablen im Web Interface vom Git Server?
Wäre tatsächlich meine Präferenz. Die sollten dann natürlich auch nur dann eingebunden werden, wenn sie nötig sind und entsprechend geschützt.

Bei Gitlab könnte man beispielsweise den Master-Branch als "protected" markieren und beispielsweise 2 Reviewer verlangen oder die Pushberechtigten einschränken oder dergleichen. Jedenfalls kontrollieren welcher Code dort landet. Entsprechende Secrets könnte man dann ebenfalls als "protected" markieren, damit sie nur auf von diesem Branch definierten Jobs und Code verwendet werden können.

> - Implizit (CD server zieht das repo und hält selbst die credentials fürs
> deployment)?
Kommt denke ich drauf an, wie man das System aufgebaut hat und kann bei hohen Sicherheitsanforderungen sicher Sinn machen.
Ich bevorzuge eher "Einmalumgebungen" (Container oder VMs) und würde ungern solche Sachen auf dem CI/CD-Worker speichern. Das dürfte auch schnell blöd werden, wenn man mal mehrere davon hat.

Wenn man dem Git-Server nicht vertraut, ist das aber eine gute Option. Sollte dann aber mit signierten Commits kombiniert werden, die der CD-Server vor der Ausführung prüft.



Eine weitere, interessante Option wäre Verschlüsselung. Man speichert den/einen Key auf dem Git- oder CD-Server und verschlüsselt damit die Credentials.
Damit würde man die Versionierung beibehalten (wobei ich nicht sicher bin wie viel die bei Credentials bringt) und bräuchte nur ein Secret auf dem Server.
Könnte man von Hand implementieren aber es gibt auch Tools wie git-crypt, die das deutlich angenehmer machen (transparent für den Nutzer, mittels OpenPGP-Keys, diffs bleiben brauchbar, ...)
Würde mir bei einem öffentlichen Repo nicht reichen aber bei einem einigermaßen beschränkten fände ich das auch sehr gut.
Insbesondere wenn man OpenPGP schon zum signieren der Commits verwendet.

[Kleba]

prolemiker schrieb:
--------------------------------------------------------------------------------
> - Wie versionierst Du derlei kritische Informationen?

Ich weiß, auch über den folgenden Ansatz kann man streiten. Aber es ist bei uns und vielen mir bekannten Unternehmen üblich: Azure Key Vault (sei es für Credentials, Zertifikate o.ä.).

Klar, hier muss man dem Cloud Anbieter vertrauen. Aber ich traue MS durchaus zu mehr in Sicherheit zu investieren, als jeder self-hosted Lösung. Und eine Lücke an so zentraler Stelle in Azure könnte praktisch das Ende für einen der absehbar wichtigsten Geschäftszweige von MS sein, weshalb ich glaube, dass das eine gewisse Priorität bei MS hat.

[Eisklaue]

Weiß nicht was ihr für ein Tool zur Source Code Verwaltung und CI/CD benutzt aber wir haben Gitlab und "sichern" Credentials für das Deployment (Zugänge für K8s, Artifactory und Co) in den Gitlab Integration Settings. Entweder auf Repo Ebene oder Gruppen Ebene, je nachdem ob ein Projekt aus mehrere Sub Projekten besteht oder es nur ein einzelnes ist. Auf die Gitlab Integration Settings hat nur ein kleiner Teil der User Zugriff. Alle anderen internen Application Credentials wie Accounts für DB, Elastic, WebServer und so werden random während des deployments mittels K8s/Helm erzeugt.

[mmhj]

Wie sichert ihr die Credentials aus den Gitlab Integration Settings?
Wie erhaltet ihr Zugang zu den Credentials für DB / Elastic / WebServer, ... - wenn benötigt?

[prolemiker]

Kleba schrieb:
--------------------------------------------------------------------------------
> Ich weiß, auch über den folgenden Ansatz kann man streiten. Aber es ist bei
> uns und vielen mir bekannten Unternehmen üblich: Azure Key Vault (sei es
> für Credentials, Zertifikate o.ä.).

Ist halt wieder vendor locking, aber schau ich mir mal an. Terraform scheint ja inzwischen recht portabel zwischen den Cloud-Diensten.
Manchmal werden Entscheidungen den Cloud Provider zu wechseln von Menschen getroffen, die nie damit arbeiten, aus Gründen, die mit dem Produkt selbst nichts zu tun haben.

[prolemiker]

Eisklaue schrieb:
--------------------------------------------------------------------------------
> Weiß nicht was ihr für ein Tool zur Source Code Verwaltung und CI/CD
> benutzt aber wir haben Gitlab und "sichern" Credentials für das Deployment
> (Zugänge für K8s, Artifactory und Co) in den Gitlab Integration Settings.

Ja, so ähnlich habe ich es auch in manchen Projekten angefangen. Es ist nur doch sehr unübersichtlich und irgendwie stört es mich, gezwungen zu sein, durch ein Webinterface zu klicken, um an die Einstellungen zu kommen bzw. diese zu ändern. Und ganz unter uns, ich finde GitLab war ein Fehler, spezielle CI/CD systeme sind deutlich besser - darum möchte ich auch vermeiden, zu sehr darauf zu setzen, in der Hoffnung, es irgendwann zu ersetzen.

[Kleba]

prolemiker schrieb:
--------------------------------------------------------------------------------
> Ist halt wieder vendor locking

True dat. Aber bei Unternehmen, wo fast die gesamte Unternehmensausrichtung auf MS Produkten aufbaut ist das zu verkraften (da ist der Lock-In-Effekt eh schon irre groß).
Wollte das auch nicht promoten oder so, sondern nur als eine Möglichkeit nennen. Azure Key Vaults können halt in den genutzten Plattformen (Azure DevOps, GitHub, etc.) überall easy eingebunden werden.

> Terraform scheint ja inzwischen recht portabel zwischen den Cloud-Diensten.
> Manchmal werden Entscheidungen den Cloud Provider zu wechseln von Menschen
> getroffen, die nie damit arbeiten, aus Gründen, die mit dem Produkt selbst
> nichts zu tun haben.

Leider ja :(