Source Code verschlüsseln

[Assarbad]

Zitat von sakura:

Zitat von Sherlock:

Zeit, Energie und am Ende sogar Geld in sowas zu verschwenden ist...nunja, Verschwendung. Wer Leute einstellt, denen er nicht vertrauen kann, macht an der Stelle bereits einen Fehler.

Ich denke, gerade wenn es um Firmengeheimnisse geht, dann ist es ein Fehler einfach jedem zu vertrauen. Und es ist auch nicht nötig. Von daher kann ich den Grund gut verstehen. Schließlich kann man in ein, zwei Job-Interviews niemals einen Menschen komplett kennen lernen. Je nach Branche werden auch Leute bewusst eingeschleust, um Firmengeheimnisse auszuspähen, von daher kann ich Deinen Beitrag überhaupt nicht nachvollziehen.

Sorry, da lach ich mich scheckig. Als Rückentwickler lernt man vor allem eins: daß Leute ihre tollen Firmengeheimnisse und ihren endgeilen Code total überschätzen. Und Mitarbeiter einschleusen mag vielleicht bei Firmen der Größe von Google, Microsoft oder Amazon klappen, gehört aber ansonsten wohl eher in den Bereich Verschwörungstheorien.

Bin da voll bei Sherlock.

Erstens: wenn ich einen Entwickler an meinen Code ranlasse, dann vertraue ich ihm. Punkt. Gegenteilige Maßnahmen sind ähnlich "zielführend" (lies: bescheuert) wie einem Kunden nicht zu vertrauen, daher starke Kryptographie einzusetzen und dennoch alle Informationen auf dem Kundenrechner vorzuhalten (inkl. geheimer Schlüssel; anstatt bspw. "Wissen" - bspw. in Form eines Algorithmus - in einen Hardwaredongle auszulagern). Das ist in sich widersinnig. Entweder du vertraust, oder du vertraust nicht. Beides geht nicht. Und im Zweifel nervst du ohnehin nur die Kunden, bzw. in diesem Fall die Entwickler. Klar kann man das machen, aber es ist halt Schlangenöl.

Aber technische Maßnahmen für soziale Probleme waren ohnehin noch nie eine Lösung.

Und ohnehin frage ich mich was genau ein Dieb denn mit den Quellen machen kann. Bei 1:1-Nutzung würde er/sie sich jedenfalls strafbar machen. Das ist ungefähr wie das Argument ein Arbeitnehmer könne sich beim Verlassen der Firma den Quellcode mitnehmen:

1. Wozu?
2. Wie soll ich den danach "nutzen" (also bspw. zu Geld machen)?
3. FLOSS-Projekte würden vermutlich nicht existieren, gäbe es nicht räudigen, verkrusteten Legacy-Code der nach Vorgaben von Firmen über Jahrzehnte von verschiedenen Entwicklern mit verschiedenster Fachkompetenz ineffizient zusammengeklöppelt werden mußte, anstatt die richtigen Werkzeuge und Methoden zu verwenden und dem Ganzen eine schöne Testabdeckung zu spendieren und ihn regelmäßig auf den Stand der Zeit anzuheben (Refactoring). Womit wir wieder bei der Überschätzung des ach so wertvollen Codes wären.

Hier wird zwar nicht viel vom Themenersteller verraten, aber wenn es um Interop geht, ist RCE ohnehin in der EU legitim. Dem kommt man also nicht einmal mit rechtlichen Mitteln bei.

Zitat von Sherlock:

In meinem Feld, den Medizinprodukten, ist das anspruchsvolle nicht die Entwicklung, sondern die Dokumentation, und Normkonformität. Und die beiden letzteren Punkte sind ohnehin in großen Teilen einsehbar.

Oh Gott, den Bereich haben wir bei uns auch. Haufenweise Vorgaben; aber viele Häkchen scheinen nur proforma gemacht zu werden. Anders kann ich mir diverse unsinnige, teils komplett kosmetische, Kodierrichtlinien bspw. nicht erklären. Da wären Regeln ala MISRA C/C++ schon zielführender.

Zitat von mensch72:

https://www.oreans.com/CodeVirtualizer.php

so als "kleine Hürde" kommt das dem von dir gesuchtem schon sehr nah

Ja? Schonmal probiert? Also das rückzuentwickeln? Sicher, Logik zu verschleiern könnte ein wenig helfen. Vor allem hält es Skriptkiddies ab.

Aber angenommen es handelt sich bei den besagten Cola-Rezepten um die endgeilsten 100 Codezeilen die jemals geschrieben wurden. Dann gibt es grob gesehen zwei Varianten:

1. Die sind endgeil, weil sie superschnell sind. Virtualisierung (Themida ist da sozusagen der Großvater von) macht dir das alles zunichte. Muß man halt wollen.
2. Das ist so endgeil, daß ein Konkurrent nicht den Aufwand scheut einen Rückentwickler dranzusetzen.

In letzterem Fall hast du schon verloren. Denn inzwischen bietet wirklich jeder aktuelle Disassembler die Möglichkeit Prozessormodule zu schreiben (mithin also die "virtuelle Architektur" zu dekodieren). Klar, bedeutet etwas mehr Aufwand, aber wenn der Code so endgeil ist, dann sind das Peanuts im Vergleich zum Nutzen für die Konkurrenz.

Aber zumeist wird es einfach ausreichen alles drumherum zu instrumentieren. Du würdest dich wundern was sich mit PIN, DynamoRIO, Wine oder auch mit Virtualisierung so alles herausbekommen läßt. Von DLL-Placement-Angriffen, die du mit einer Auftrennung in Module u.U. noch erleichterst, haben wir dabei noch nicht einmal geredet.

Es scheint sowieso ein komplett falscher Eindruck von Rückentwicklung (RCE = Reverse Code Engineering) zu existieren. Die Schnittstellen zu einem solchen "geschützten" Modul wären ja dennoch recht einfach für einen Rückentwickler zu ermitteln.

So, dann hab ich also eine Schnittstelle. Jede Menge "Geschäftscode" den ich - als "interessierter Konkurrent" - so oder so ähnlich ohnehin schon habe und/oder kenne. Aber dann habe ich da ein extra geschütztes Modul. Jetzt rate mal worauf genau sich meine Aufmerksamkeit konzentrieren wird?!

Als Rückentwickler guckst du ja nicht nach dem ganzen Boilerplate-Code der überall 08/15 ist, sondern du guckst nach den wenigen Prozent oder gar Promille die interessant sind. Um das Arbeitsfeld einzugrenzen hilft so ein vermeintlicher Schutz also auch erst einmal. Und klar, diese Teile ala Themida sind echt nervig, aber sie sind nicht unknackbar. Wenn ich also das fertige Endprodukt erwerben kann und sich daraus ergibt, daß sich der Aufwand lohnt, dann ist der Schutz trotzdem allenfalls das was man von diesen ganzen Spieleschutztechniken kennt: ein paar Wochen oder Monate. Bei Spielen lohnt sich das häufig, weil die ganzen Spieler den Herstellern bei Veröffentlichung die Bude einrennen und das dann abebbt. Aber wie man schon der Tatsache, daß diese Schutzmechanismen in Spieleupdates oft wieder verschwinden, entnehmen kann, ist der Effekt zeitlich begrenzt. Wäre dies bei der hier avisierten Schutzmaßnahme auch der Fall? Klingt nicht danach.

Echten Schutz bekommst du nur, wenn die eigentliche proprietäre Logik nicht für den, dem man nicht vertraut, zugreifbar ist. Also in einem "smarten" Hardwaredongle oder serverseitig. Was dann natürlich wieder andere Einschränkungen mit sich bringt.

Und nein, diese Form von Sicherheit läßt sich nicht kaufen. Ich habe schon mehrere Hardwaredongle geknackt und das Problem lag immer in unzureichendem Schutz auf Seiten des PC. Im einen Fall wurde sogar nur ganz stupide ein Wert ausgelesen und an die Anwendung übergeben. Ohne den Code der Anwendung oder seine DLLs auch nur anzufassen, habe ich da einfach eine eigene DLL plaziert, die den Wert genauso zurückgab. Wunderbar. Problem (Parallel-Hardwaredongle "schützen", denn die waren sehr fragil) gelöst. Das Programm wurde dennoch nur entsprechend der Anzahl der Lizenzen eingesetzt und falls - was ich nie überprüft habe - diese Zahl mehr als eine Lizenz- oder Kundennummer war und bspw. die Features des Programms kodierte, habe ich das nicht ausgenutzt. Es ging ganz simpel darum, daß bei Ausfall des Dongles ("durchbrennen") oder anderen Unwägbarkeiten der Geschäftsbetrieb aufrechterhalten werden konnte.

Und bei alledem kommt die Diskussion der Sinnhaftigkeit noch immer zu kurz, denn "mein" Entwickler, den ich anstelle, soll ja nicht etwa nur in der Lage sein Code zu entwickeln, sondern diesen auch zu debuggen. Ich schieße mir also mittelfristig damit selbst ins Knie. Von der desaströs demotivierenden Botschaft, die von derlei Verfahrensweise ausgeht, ganz zu schweigen.

Zitat von IBExpert:

Da kann ich dir von diversen Kunden und sogar von ehemaligen eigenen Mitarbeitern
durchaus interessante Geschichten erzählen, aber garantiert nicht hier ...

Es ist auch nicht so, das immer nur der unten in der Hierarchie das A...loch ist und mit
seinem Know How abhaut, oft ist es auch ein Wechsel in der Geschäftsführung, die den
Chefarchtekt hinter einer gesamten Softwarelösung in die Selbstständigkeit treiben
und warum sollte dieser sein Branchen Know How nicht woanders einsetzen, verträge
hin oder her ....

Du willst uns also allen Ernstes erklären, daß das BGB (Verträge) und Urheberrecht zahnlose Papiertiger sind?

Zitat von Hobbycoder:

Nicht selten werden Mitarbeiter, die über entsprechendes internes Wissen verfügen, genau deswegen von anderen Firmen oder Konzernen für viel Geld abgeworben.

... und dann ggf. wegen Verrats von Geschäftsgeheimnissen zur Verantwortung gezogen.

Zitat von Benmik:

Wenn ich die Charakterstruktur von Programmierern bisher richtig kennen gelernt habe, dann ist dies ein unwiderstehlicher Anreiz, diese Abwehr zu knacken, auch für solche Leute, die ursprünglich gar kein Interesse am Geheimnis an sich hatten. Eine ganze Reihe der Maßnahmen kann man ohne Mühe durch einen einfachen Code-Formatierer wieder beseitigen. Dann noch ein paar kleine Helferlein geschrieben... Also, dieser Schuss könnte nach hinten losgehen.

Eben. Allerdings wird man sich in einem Kundenverhältnis zumeist anders einig, weshalb es häufig unnötig ist zu derlei Maßnahmen zu greifen.

Nochmal: wenn du deinen Entwicklern nicht vertrauen kannst, haste ein ganz dickes Problem. Wer den Feind eben bereits im eigenen Hause verortet, sollte sich mal echt Gedanken machen. Entweder bringst du deinen Entwicklern nicht die Wertschätzung entgegen, du bezahlst sie nicht entsprechend ihrer Qualifikation oder es gibt andere Gründe.

Und ja: Programmierer != Entwickler (hier nochmal auf Delphi: Programmier <> Entwickler )

[Benmik]

Zitat von Assarbad:

Wenn du deinen Entwicklern nicht vertrauen kannst, haste ein ganz dickes Problem.

Das hat man vielleicht. Aber ich vermute mal vorsichtig, dass du in deinem Leben noch nicht so viele Leute eingestellt hast. Ich habe da schon erhebliche Erfahrung und man glaubt gar nicht, was sich hinter Leuten verbergen kann, die tadellose Zeugnisse anbringen und im Bewerbungsgespräch (und in den ersten Monaten danach) eine absolut gute Figur machen. Ich bin zu dem Schluss gekommen, dass es einfach unmöglich ist, alle Bewerber auch nur rudimentär zu durchschauen. Es gibt eine Regel für Leute mit Führungsaufgaben: Ab 10 Mitarbeitern geht die Chance, dass du einen schwierigen Fall darunter hast, gegen 100%. Solche Fälle können sich auch mit den Jahren entwickeln. In einer großen Firma, wie der TE schreibt, ist es praktisch zwangsläufig so, dass es dort schwierigste Kollegen gibt.

Ich habe mal den Fall erlebt, dass sich einer unserer Systembetreuer von zuhause aus ins System eingeloggt hat, um es komplett zu sabotieren. Das Ganze ohne erkennbaren Grund und ohne finanziellen Gewinn. Er hinterließ allerdings digitale Spuren, an die er hinterher nicht mehr herankam, so dass er nach dem Ausloggen zuhause saß und auf die Polizei wartete. Ich kannte den Mann auch. Alle waren platt; nie, nie hätte man dem das zugetraut.

Ich meine auch, dass du unterschätzt, wie sehr die Existenz einer Firma von einem bestimmten, vielleicht sogar eng begrenzten Spezialwissen abhängen kann. In der Industrie sind das oft Verfahrenstechniken; wenn dein Schatz sich in einem Stück Software materialisiert, dann ist es existenziell, dass du das schützt. Ich persönlich würde dafür auch ein hohes Maß an Umbequemlichkeit in Kauf nehmen. Alles andere fände ich sehr naiv.

[sakura]

Zitat von Assarbad:

Sorry, da lach ich mich scheckig. Als Rückentwickler lernt man vor allem eins: daß Leute ihre tollen Firmengeheimnisse und ihren endgeilen Code total überschätzen.

Hi Assarbad, ich habe immer großen Respekt vor Deinem Wissen gehabt, insbesondere Deine Qualitäten auf genau dem Gebiet. Und Entwickler mit Deinem Wissen auf diesem Gebiet mit Deinem Know-How gibt es einige, aber gemessen an der Gesamtzahl aller Entwickler ist das ein extrem kleiner Anteil. Und (fast) jeder hier weiß, dass für alles, was ein Computer ausführen kann, jemand auch mehrere Entwickler existieren, die das verstehen werden, egal wie komplex und verschleiert es ist. Aber das heißt nicht, dass man es der Konkurrenz zu leicht machen sollte. Im Gegenteil, bei diese Einstellung ist lächerlich.
Und zu glauben, dass solche Dinge nur bei den großen auftreten, das ist extrem naiv. Ich habe für kleine Unternehmen gearbeitet, denen das passiert ist, und ich kenne mehrere Firmen aus meinem alten Kundenkreis, welche dieses Problem ernsthaft hatten. Keiner hat erwartet, dass es 100% Schutz gibt, insbesondere bei Programmen, welche auch außer Haus installiert wurden (sehr oft). Aber keiner wollte es der Konkurrent dann auch zu leicht machen. Ein Wissensvorsprung, auch in Software, von nur ein paar Wochen kann Millionen Umsatz bedeuten. Und das sollte einem Entwickler mit Deiner Intelligenz eigentlich auch verständlich sein, oder?

......

[TigerLilly]

Die Frage des Te war:

Zitat:

Welche Möglichkeiten habe ich, bestimmte Units für andere Entwickler nicht sichtbar zu machen.

Und wir reden jetzt darüber, warum er diese Frage gar nicht stellen soll? Wie schon gesagt, es gibt Branchen, da ist das ist das ein Muss.

[dummzeuch]

Um das Ganze mal abzukürzen:

• Es ist sinnlos zu versuchen den Sourcecode zu "verschlüsseln" (Code obfuscation). Alle Methoden, die es dazu gibt, lassen sich mit mehr oder weniger großem Aufwand rückgängig machen. Wenn das "Geheimnis" wirklich so wichtig ist, wird jemand diesen Aufwand treiben. Und außerdem sind die meisten Softwareentwickler von Natur aus neugierig und ein solcher Code würde sie dazu bringen, zu versuchen in wieder lesbar zu machen.
• Also darf man nicht den Sourcecode sondern nur eine binäre Form herausgeben (dabei nicht vergessen: Auch für diesen Teil des Sourcecodes sollte man ein SCM verwenden! Zugriffsbeschränkungen sind da ja möglich.). Das können DCUs oder eine DLL sein.
• Wenn es Abhängigkeiten gibt, die letzteres verhindern, muss man diese mittels Refactoring entfernen. Wenn das "Geheimnis" wirklich so wichtig ist, dann muss man diesen Aufwand treiben. (-> Entscheidung trifft der Firmenchef oder wie hoch auch immer sie aufgehängt werden muss.)

[sakura]

Wenn es eine in-house Anwendung ist, dann gäbe es noch die Möglichkeit, die Routinen ausschließlich über einen REST-Server anzubieten. Hier kommt es natürlich auf die Umstände an, wie diese Berechnungen benötigt werden.

Zitat von Sherlock:

In meinem Feld, den Medizinprodukten, ist das anspruchsvolle nicht die Entwicklung...

oder eine Kombination daraus. Oocyten-Stadium und Qualitätserkennung ist weiterhin einer der Bereich eines ehemaligen AGs von mir, auf dessen Gebiet dieser führend ist. Auch darauf hatten nur sehr wenige Entwickler Zugriff. Selbst die Kunden haben die Routinen nie bekommen. Auch diese Dinge wurden ausschließlich über REST angeboten. Und dann kam die wunderbare Doku für weltweite Zulassungen hinzu. Oh ja...

......

[Assarbad]

Zitat von sakura:

Und (fast) jeder hier weiß, dass für alles, was ein Computer ausführen kann, jemand auch mehrere Entwickler existieren, die das verstehen werden, egal wie komplex und verschleiert es ist. Aber das heißt nicht, dass man es der Konkurrenz zu leicht machen sollte. Im Gegenteil, bei diese Einstellung ist lächerlich.

Erstmal: es ging hier nicht um die Konkurrenz, es ging um die Entwickler im eigenen Hause. Diese Entwickler haben - schon von Rechts wegen - eine Verpflichtung zur Loyalität, genau wie (bspw. in der aktuellen Situation) die Firma eine Fürsorgepflicht hat.

Den Konkurrenten muß es niemand einfach machen. Aber nochmal: wer den Feind (sprich: den Konkurrenten) bereits im eigenen Hause verortet hat größere Probleme als das "Cola-Rezept" vor seinen Entwicklern zu schützen. Ohnehin ließe sich Schaden seitens eines Konkurrenten deutlich subtiler anrichten als durch den Klau von Firmengeheimnissen.

Zitat von sakura:

Und zu glauben, dass solche Dinge nur bei den großen auftreten, das ist extrem naiv.

Mag sein. Ich halte es wiederum naiv davon auszugehen, jemand begäbe sich freiwillig und sehenden Auges in eine Vertragssituation gegenüber dem Konkurrenten um diesen auszuspähen. Da halte ich es doch für deutlich wahrscheinlicher, daß man bei der Reinigungsfirma des Konkurrenten anheuert und die Tatsache ausnutzt, daß es 1. Lücken in Software gibt 2. Lücken in sicherheitsrelevanten Richtlinien gibt (bspw. das Sperren des Rechners beim Weggehen, was mit Vorliebe die Leute mit den weitgehendsten Rechten "nervig" finden, weshalb sie sich von den entsprechenden Vorgaben entbinden lassen). Sichwort in diese Richtung: BadUSB. Der kleine USB-Stick vom Parkplatz könnte sich aus Kombination von Eingabegeräten und Massenspeicher mit drahtloser Netzwerkanbindung entpuppen, die wie von Geisterhand ungesperrte Rechner übernimmt. Oder in unserem Szenario übernimmt das Anstecken und Abziehen - alles in unter einer Minute - die unterbezahlte Putzfrau aus Südosteuropa gegen eine kleine finanzielle Anerkennung. Es gibt dutzende kommerziell verfügbare Gadgets, die sich statt von einem seitens der eigenen Firma angeheuerten Pentester auch von einem böswilligen Angreifer nutzen lassen. Mit rudimentärer Kenntnis des Zielsystems kann man erstmal "den Fuß in die Tür kriegen und diese dann weiter aufstoßen". Selbst gebastelt oder beim Auftragsfertiger in China bestellt macht das noch schwieriger nachzuverfolgen, falls der Agent ertappt wird.

Zitat von sakura:

Ich habe für kleine Unternehmen gearbeitet, denen das passiert ist, und ich kenne mehrere Firmen aus meinem alten Kundenkreis, welche dieses Problem ernsthaft hatten.

Ich bin mir nicht sicher welchen Aspekt du hier ansprichst. Dir sind viele Fälle von eingeschleusten Getreuen der Konkurrenz bekannt, oder dir sind viele Fälle von entwendetem "geistigen Eigentum" bekannt?

Zumindest wenn der Konkurrent, anstatt jemanden einzuschleusen, einfach über RCE einen Klon erstellen, würde dies ebenfalls rechtliche Fragen aufwerfen und dem eigentlichen Urheber gewisse juristische Mittel an die Hand geben.

Wenn du sagst dieses Thema sei extrem verbreitet auch bei kleineren Firmen, stellt sich die Frage warum die Rechtsmittel dann nicht ausgeschöpft werden? Wird die Schöpfungshöhe bei diesen "Cola-Rezepten" am Ende doch nicht erreicht? Oder ist das "Cola-Rezept" am Ende weniger wert als den Konkurrenten mit dem eigenen Werk ziehen zu lassen?

Abgesehen davon stellt sich natürlich die Frage, ob man nicht eventuell die vielen Stunden, Tage oder Wochen, die für solche Schlangenölmaßnahmen aufgewendet werden in Qualitätssicherung und Weiterentwicklung der Software stecken sollte?! Da freuen sich die Kunden und man macht es dem Konkurrenten so auch schwer.

Man stelle sich vor der Themenersteller "sichert" das alles mit einem tollen Drittanbieter-Schlangenöl-Werkzeug (was in sich schon Projektrisiken birgt) und der eigentliche Code landet (im Klartext) in einem separaten SCM. Wird denn HTTPS bzw. SSH im Firmennetz verwendet? Teilt man sich - auch mal aus Versehen - Paßwörter? Läuft der selbstgehostete Chatdienst auch mit Transportverschlüsselung? Wie ist denn so insgesamt die Sicherheit im Netzwerk? Kurzum: wir drehen uns im Kreis und landen wieder bei meiner Aussage von letzter Nacht, daß, wer den Feind im eigenen Haus verortet, größere Probleme hat als mit dieser Methode sich und anderen "Sicherheit" vorzugaukeln.

Zitat von sakura:

Keiner hat erwartet, dass es 100% Schutz gibt, insbesondere bei Programmen, welche auch außer Haus installiert wurden (sehr oft). Aber keiner wollte es der Konkurrent dann auch zu leicht machen. Ein Wissensvorsprung, auch in Software, von nur ein paar Wochen kann Millionen Umsatz bedeuten. Und das sollte einem Entwickler mit Deiner Intelligenz eigentlich auch verständlich sein, oder?

Nochmal: es ging dem Themenersteller um Entwickler im eigenen Hause, die man als Agenten der Konkurrenz vermutet.

Das andere Thema habe ich selbst aufgeworfen (zeitlicher Vorsprung) und stelle es somit nicht infrage. Die Schlußfolgerungen stelle ich hingegen sehr wohl infrage. Wir landen also nicht beim Konsenseinheitsbrei, sondern bei einem Dissens; und trotzdem haben alle etwas gelernt.

Zitat von sakura:

Wenn es eine in-house Anwendung ist, dann gäbe es noch die Möglichkeit, die Routinen ausschließlich über einen REST-Server anzubieten. Hier kommt es natürlich auf die Umstände an, wie diese Berechnungen benötigt werden.

Eben!

Zitat von Assarbad:

Echten Schutz bekommst du nur, wenn die eigentliche proprietäre Logik nicht für den, dem man nicht vertraut, zugreifbar ist. Also in einem "smarten" Hardwaredongle oder serverseitig. Was dann natürlich wieder andere Einschränkungen mit sich bringt.

[joachimd]

Zitat von Assarbad:

Aber nochmal: wer den Feind (sprich: den Konkurrenten) bereits im eigenen Hause verortet hat größere Probleme als das "Cola-Rezept" vor seinen Entwicklern zu schützen. Ohnehin ließe sich Schaden seitens eines Konkurrenten deutlich subtiler anrichten als durch den Klau von Firmengeheimnissen.

87% aller Informationssicherheitsverletzungen gehen von den eigenen Mitarbeitern aus ... und von den Wenigsten wissentlich bzw absichtlich. Ich finde es daher schon sinnvoll, dass man _jedem_ Benutzer nur die notwendigsten Zugriffsrechte gibt. Egal, wie sinnvoll Dir jetzt ein Cola-Rezept erscheint, aber die Firma hat es als schützenswert eingestuft und hier geht es darum, wie man es technisch umsetzen kann.
Wenn die Mitarbeiter an gewisse Information nicht kommen, können diese sie auch nicht unabsichtlich weitergeben (und wenn es "bloß" Ausspähen durch Schadsoftware ist).
Zur technischen Umsetzung: ist es für die Entwicklung wichtig, das richtige Rezept zu haben? Wenn nicht, Stichworte wie MockUp, Fake-Daten usw sind ja schon gefallen. Erst das endgültige Resultat nutzt eben die echte Unit. Damit schränkt man den Zugriff auf wenige Projekt Owner ein.

[Assarbad]

Zitat von joachimd:

87% aller Informationssicherheitsverletzungen gehen von den eigenen Mitarbeitern aus ... und von den Wenigsten wissentlich bzw absichtlich.

Keine Ahnung was die Quelle ist, klingt aber prinzipiell plausibel. Jetzt frage ich mich halt welcher Prozentsatz davon wiederum auf die verschwunden gegangenen Firmengeheimnisse entfällt und wie viel davon wiederum Entwicklern angelastet werden kann?! Gibt's dazu auch aussagekräftige Zahlen?

Zitat von joachimd:

Ich finde es daher schon sinnvoll, dass man _jedem_ Benutzer nur die notwendigsten Zugriffsrechte gibt.

Klar, soziale Probleme mit technischen Maßnahmen "erschlagen" ist bekanntlich ein Lieblingsthema der inkompetentesten IT-Abteilungen. Firmen schulen ihre Mitarbeiter zwar in Arbeitssicherheit und dazu was zu tun ist wenn der Feueralarm losgeht, meist mindestens jährlich, aber Schulung der Mitarbeiter in Grundlagen der IT-Sicherheit durch die IT-Abteilungen ist ein Unding, weil das Kontakt der IT mit echten Menschen erfordern würde; und eine Behandlung der Benutzer die nicht "von oben herab" und abschätzig den "LUsern" gegenüber ist, sondern Wissensvermittlung auf Augenhöhe und Offenheit für Rückmeldungen auch von Laien erfordert.

Und das sage ich ausdrücklich als ehemaliger Admin der jetzt nicht gerade die große Leuchte im Umgang mit Leuten (also keine "people person") ist, der aber gelernt hat, daß IT-Sicherheit durch technische Maßnahmen nur marginal verbessert wird, durch Wissenstransfer zu den "Anwendern" hingegen fundamental.

Bin ein großer Verfechter des Zero-Trust-Ansatzes in internen Firmennetzen. Aber wenn für alle möglichen Autoritätspersonen innerhalb der Firmenhierarchie ohnehin Extrawürste gebraten werden (weil die ihre "Managerkarte" zücken), ist das eben kein Zero-Trust und fällt auseinander bevor es zusammengebaut ist. Oder anders ausgedrückt: du kannst zwar deine "Bodentruppen" (die Entwickler) mit Scheinsicherheit gängeln, aber wenn die sehen, daß das Scheunentor woanders offen gelassen wird, schwindet die Akzeptanz für solche Maßnahmen ganz schnell. Dazu haben die meisten Entwickler zu viel Einblick in die Materie ... und mindestens deutlich mehr als die Buchhalterin oder der Assistent des Geschäftsführers.

Zitat von joachimd:

Egal, wie sinnvoll Dir jetzt ein Cola-Rezept erscheint, aber die Firma hat es als schützenswert eingestuft und hier geht es darum, wie man es technisch umsetzen kann.

Das Framing "wie man es technisch umsetzen kann" ist genau der Punkt den ich bemängele. Wenn dich jemand fragt wie er am besten mit nem Hammer das Bücherregal an der Leichtbauwand festschraubt empfiehlst du doch auch nicht besonders fest draufzuhauen oder lieber einen Drittanbieterhammer zu benutzen, oder?

Zitat von joachimd:

Wenn die Mitarbeiter an gewisse Information nicht kommen, können diese sie auch nicht unabsichtlich weitergeben (und wenn es "bloß" Ausspähen durch Schadsoftware ist).

Die stärkste Kette ist nur so stark wie ihr schwächstes Glied.

Und klar, nix dagegen das zu trennen (separates Repo wurde ja schon genannt). Absolut nicht. Besonders wenn man Praktikanten/Werksstudenten im Hause hat, möchte man da sicher eine Abstufung des Zugriffs auf die "Kronjuwelen". Diese Abstufung klang im Beitrag eingangs aber nicht an. Und wenn der Zugriff auf das Repo mit dem "Cola-Rezept" eingeschränkt ist und ein Mock während der Entwicklung existiert braucht es eben keine Schlangenöllösung.

[IBExpert]

Zitat von Assarbad:

Zitat von IBExpert:

Da kann ich dir von diversen Kunden und sogar von ehemaligen eigenen Mitarbeitern
durchaus interessante Geschichten erzählen, aber garantiert nicht hier ...

Es ist auch nicht so, das immer nur der unten in der Hierarchie das A...loch ist und mit
seinem Know How abhaut, oft ist es auch ein Wechsel in der Geschäftsführung, die den
Chefarchtekt hinter einer gesamten Softwarelösung in die Selbstständigkeit treiben
und warum sollte dieser sein Branchen Know How nicht woanders einsetzen, verträge
hin oder her ....

Du willst uns also allen Ernstes erklären, daß das BGB (Verträge) und Urheberrecht zahnlose Papiertiger sind?

Jein, es ist ist in diesem Umfeld erstens ein sehr großes Problem, das vor Gericht
ohne jeden Zweifel zu beweisen.

Wissen über Prozessdetails bzw Anklage des Mißbrauchs sind ohne umfassendes Patent
nicht wirklich erfolgreich einklagbar. Und zumindest in Deutschland wirst nicht
mit vertretbarem Aufwand ein Patent für deine Software bekommen.

Jeden externen, der per reverse engineer deine Software komplett analysiert
und sich dann auf deine Verfahren und apis drauf setzt, wirst du auch nur
sehr begrenzt verklagen können, gpl etc. hin oder her, warum sollte er deine
Sourcecodes benutzen. Vielleicht ist es ja auch deine Schuld, das deine API
zu banal ist und schon ist da kein klarer Sieger mehr sichtbar.

Da kannst du ansonsten sehr viel gutes Geld dem verlorenen schlechten Geld
hinterher schmeißen und am meisten freuen sich die Anwälte, die am Ende
im Vergleichsverfahren ihr volle Kohle von beiden Parteien bekommen und
gewonnen hast du gar nichts.

Recht haben und Recht bekommen sind zwei völlig verschiedene Baustellen.