it-swarm.com.de

Ist es dringend erforderlich, den Zugang zu einem privaten Repo zu widerrufen, sobald einer Person fälschlicherweise der Zugang gewährt wurde, und sich dessen bewusst zu werden?

Es gab einen Beitrag auf Niebezpiecznik.pl , einen beliebten InfoSec-Blog, der eine interessante Situation beschreibt.

Ein Unternehmen hat einem zufälligen Programmierer fälschlicherweise Zugriff auf sein BitBucket-Repo gewährt. Dieser Programmierer alarmierte anschließend verschiedene Mitarbeiter des Unternehmens und forderte sie auf, den Zugriff so schnell wie möglich zu widerrufen. Er fand diese Mitarbeiter träge (zum Beispiel sagte einer, er würde den Zugang erst widerrufen, wenn er von seinem Urlaub zurück war), und alarmierte den Niebezpiecznik-Blog, der sich anschließend an das Unternehmen wandte. Erst dann wurde der Zugang widerrufen.

Es ist klar, dass der Programmierer das Fehlen eines sofortigen Widerrufs des Zugriffs als ein sehr schwerwiegendes Versehen im Namen der Sicherheitspolitik des Unternehmens ansah. Und hier bin ich überrascht.

Betrachten wir dies aus Sicht des Unternehmens. Jemand kontaktiert sie, behauptet, ihm sei fälschlicherweise Zugang zu ihrem privaten Repo gewährt worden, und fordert sie auf, diesen Zugang zu widerrufen. Jetzt ist diese Person entweder am Inhalt dieses Repos interessiert oder nicht; Er hat auch moralische Werte, die nicht stark genug sind, um sie nicht herunterzuladen. Wenn er bereit ist, den Inhalt des Repos zu überprüfen, hatte er bereits genügend Zeit, dies zu tun. und wenn er dies noch nicht getan hat, wird er dies wahrscheinlich noch nicht getan haben, wenn der Mitarbeiter von seinem Urlaub zurück ist. Mit anderen Worten, die Milch ist bereits verschüttet und nichts Schlimmeres als das, was bereits geschehen ist, wird wahrscheinlich in Zukunft passieren.

Infolgedessen, denke ich, ist die Situation nicht mehr dringend und kann gut warten, bis der Mitarbeiter aus seinem Urlaub zurück ist.

Wo irre ich mich

60
gaazkam

Es gibt mehrere Gründe:

  • Wenn es einer Person passiert ist, ist es möglicherweise mehr passiert. Diese anderen Leute könnten nicht so freundlich sein.
  • Wer weiß, diese Person könnte ihre Meinung ändern. Wenn sie sich bemüht haben, Sie zu kontaktieren, und dafür nur ein "meh" erhalten, sind sie möglicherweise etwas verärgert und beschließen, Sie dafür zu bestrafen.
  • Oder vielleicht wollen sie nur zum Spaß ein bisschen herumstöbern und versehentlich etwas kaputt machen.
  • Sie möchten wahrscheinlich die Protokolle überprüfen, um festzustellen, ob diese Person die Wahrheit sagt. Vielleicht haben sie stillschweigend Ihre Verschlüsselungsschlüssel gestohlen, bevor sie Sie kontaktiert haben. Sie möchten wahrscheinlich alle Ihre Geheimnisse drehen, nur um sicherzugehen.
  • Und vor allem ist dies ein Big F * cking Deal ™. Wer nicht mit Schock und Entsetzen reagiert, sondern eine andere Piña Colada bestellt, versteht den Ernst der Lage eindeutig nicht.

Es gibt einige sehr gute Punkte in Kommentaren und diese Antwort , dass unter bestimmten Umständen alles in Ordnung sein könnte (z. B. Nur-Lese-Zugriff, keine Geheimnisse im Code usw.). Das ist richtig, aber ich würde trotzdem argumentieren, dass dies ernster genommen werden sollte. Sind Sie wirklich zu 100% sicher, dass Ihr Repo keine Geheimnisse in einem alten Commit enthält? Die Tatsache, dass jemand, der keinen Zugriff auf Ihre Systeme haben sollte, es trotzdem bekommen hat, ist an sich schon ein schlechtes Omen.

109
Anders

Während es unmöglich ist, die Gedanken der Spieler zu lesen, würde ich denken, dass der unabhängige Programmierer

A) Möchte nicht der Unangemessenheit beschuldigt werden - Es ist viel schwieriger, des IP-Diebstahls beschuldigt zu werden, wenn Sie treten und schreien, um Ihren Zugang nach Eile zu widerrufen.

B) ist entsetzt über die Sicherheitslage des Unternehmens, das das private Repository kontrolliert, und weiß, dass er informiert werden möchte, wenn er dafür verantwortlich ist.

Zu beachten ist, dass das Gewähren eines zusätzlichen Benutzerzugriffs auf ein Repository einen völlig neuen möglichen Angriffsvektor eröffnet. Wenn eine andere Person mit böswilligen Absichten Zugriff auf das Konto hat, dem der Zugriff auf das Repo gewährt wurde, ohne dass der ursprüngliche Kontoinhaber davon Kenntnis hat, kann diese Person problemlos Ihren gesamten Quellcode herunterladen.

19
Nzall

Um eine andere Sichtweise als die Mehrheit zu bieten, sollte es wirklich kein Sicherheitsrisiko sein iff das Projekt wird gut gehandhabt.

Grundsätzlich müssen zwei Dinge erfüllt werden. Erstens das

  • Sie können keinen Code in Release-Zweige einfügen, ohne dass andere Personen ihn abmelden müssen. Dies wird normalerweise dadurch erreicht, dass Pull-Anforderungen und Codeüberprüfungen für jeden Code erforderlich sind, der in einen Release-Zweig gelangt. In diesem Fall müssen Sie sich darüber keine Sorgen machen, wenn die Person nur Lesezugriff auf das Repository hat. Trotzdem sollten Sie dies trotzdem tun.

und zweitens das

  • Niemand nimmt Geheimnisse in das Repository auf. Ja, Sie haben möglicherweise geheime API-Schlüssel, Codesignaturzertifikate und was nicht, aber die echten sollten NIE in Ihrem Haupt-Repository sein, auf das jeder zugreifen kann. Wenn einige Geheimnisse erforderlich sind, damit der Code funktioniert, fügen Sie einige Dummy-Entwicklungs-/Testversionen in Ihr Repository ein. Die realen sollten jedoch separat aufbewahrt werden, wobei nur eine kleine Anzahl von Personen Zugriff hat, vorzugsweise, damit Ihr Build-System sie automatisch ohne manuelle Beteiligung einschließt.

Wenn beides zutrifft, sehe ich aus Sicherheitsgründen keinen wirklichen Schaden. Ob der Code einige wertvolle Geschäftsgeheimnisse enthält, die einem Konkurrenten bekannt werden könnten, ist ein anderes Thema.

Oder eine andere Art, darüber nachzudenken: Die Situation hier ist nichts Besonderes. Sie müssen sich jedes Mal, wenn ein Mitarbeiter kündigt, mit denselben Problemen befassen! Wenn Ihr Repository Geheimnisse enthielt, kennt eine externe Person jetzt alle.

10
Voo

Wenn Sachen gestohlen werden, schauen Sie zuerst, welche Leute einen Schlüssel zum Safe haben.

Ich habe in der Vergangenheit getreten und geschrien, um nicht diesen Schlüssel zu haben. Wenn also (wann) etwas gestohlen wurde, würden sie mich nicht als möglichen Täter ansehen.

Dies könnte also für diesen Programmierer genauso gewesen sein. Er wollte nicht diesen Schlüssel haben.

7
Pieter B

Sie haben Recht, dass die Situation möglicherweise überhaupt nicht dringend ist und die nachlässige Reaktion der Mitarbeiter gerechtfertigt sein könnte. Vielleicht hat sich der Mitarbeiter nicht um das Problem gekümmert, weil der betreffende Code nicht mehr verwendet wurde oder er keine Geheimnisse mehr hat.

4
Booser

Ich habe einmal für ein Startup gearbeitet, bei dem alle die gleichen SSH-Schlüssel verwendeten, weil jemand dachte, es wäre einfacher, einen Schlüssel zu löschen/zu ersetzen, wenn jemand etwas Dummes tut.

Es besteht auch die Möglichkeit, dass Entwickler seinen Schlüssel auf einem öffentlich zugänglichen Computer wie einem Computer an der Universität speichern. Dies mag sehr unsicher klingen, ist aber für "Hello World" und "Practice Papers" geeignet.

In diesem Fall kann das Unternehmen, wie Sie bereits festgestellt haben, relativ sicher sein, dass die Person, die den Vorfall gemeldet hat, nicht versucht, das Unternehmen zu verletzen. Sie können jedoch nie sicher sein, wer Zugriff auf das Konto/die Schlüssel der Person hat, die den Vorfall gemeldet hat.

3
Felix

Ich lese kein Polnisch, also vergib alles, was bereits angesprochen wurde:

Bitbucket hostet Git und Mercurial Repos - beide sind verteiltes CVS; Diese sind im Allgemeinen nicht mit technologischen Kontrollen zum Schutz des geistigen Eigentums/zur Verhinderung des Austritts von geistigem Eigentum vereinbar. Jeder vorhandene Klon/jede vorhandene Gabel kann ohne zentrale Sichtbarkeit des Prüfpfads geklont werden.

Zum Ändern von Repos sollten geeignete Sicherheitskontrollen vorhanden sein, z.

  • PKI-Abmeldung für alle Commits
  • schreibgeschütztes Repo mit Pull-Anforderungen

Somit ist ein möglicher Schaden bereits angerichtet.

1
CGretski

Sicherheit ist - am Ende des Tages - eine Reihe von Prozessen und Verfahren sowie eine Denkweise. Es ist nicht ein hartes und schnelles Regelwerk. Wenn Sie der Meinung sind, dass ein System aufgrund von eins geringfügigen Verstößen anfällig ist, ist Ihre gesamte Sicherheitseinstellung bestenfalls fehlerhaft und möglicherweise nur für Henny Penny/Chicken Little nützlich.

  • Wenn Anmeldeinformationen nicht verfügbar sind, wen interessiert das? Nach meiner Erfahrung als Codierer, Linux-Systemadministrator und Sicherheitsbereinigungs-/Fixierer ist das größte Problem mit Code In einem Repo ausgesetzt zu sein, ist einfach das Risiko, dass Anmeldeinformationen offengelegt werden. Die Realität ist die meisten vernünftige Codierer wissen, wie man ohne feste Codierungsdaten in ihren Code codiert. Aber die meisten Codierer sind nur faul und wissen, warum - oder wie - jemand ein System mit Anmeldeinformationen erstellen kann, die vom Kerncode getrennt sind.

    Wenn dieses System also von vernünftigen Programmierern ausgeführt wurde und das Repo keine Anmeldeinformationen enthält, wissen Sie was? Wen interessiert das. Aber - wie viele von uns bereits wissen - gibt es beschissene Codierer auf "Mall Cop" -Ebene, die nur Anmeldeinformationen in den Kerncode einfügen, und das ist es. Du musst es nach Gehör spielen.

  • Die Offenlegung von Geschäftsgeheimnissen ist ein Risiko. Dies hängt von der Branche und den Anforderungen ab, unter denen der Code erstellt wurde. Wenn der Code für ein Blog oder eine einfache Website ist? Wie auch immer. Selbst wenn es sich um eine E-Commerce-Website handelt, wenn es sich um eine lokalisierte Kopie von etwas wie Magneto handelt, ist dies kein wirkliches Risiko, da es sich um Open-Source-Software handelt. Aber wenn diese Software proprietär und riskant wäre - wie etwas, das Finanzdaten und möglicherweise sogar heißen neuen Code für ein Spiel verfügbar machen könnte -, dann ist dies ein Risiko.

Aber am Ende des Tages besteht die Aufgabe eines "White Hat" -Hackers darin, andere über die Probleme zu informieren. Wenn sie ein "Wen interessiert das?" Einstellung zur Exposition, das ist ihr Problem. Vielleicht sehen sie wirklich kein Risiko? Vielleicht ist es ihnen wirklich egal und die Belichtung wird andere verletzen? Vielleicht sind sie Idioten? Vielleicht sind sie so intelligent, dass Code-Exposition nur - vielleicht - ein paar Tage Refactoring bedeuten würde, um das Risiko zu begrenzen? Aber am Ende des Tages kann man so viel tun, um jemanden davon abzuhalten, sich selbst zu verletzen.

1
JakeGould