Prämisse : Die Anforderungen für ein anstehendes Projekt beinhalten die Tatsache, dass niemand außer autorisierten Benutzern Zugriff auf bestimmte Daten hat. Dies ist normalerweise gut, aber dieser Umstand ist nicht üblich. Die Anforderungen besagen, dass selbst Programmierer oder andere IT-Mitarbeiter nicht auf diese Informationen zugreifen können. (Sie wollen, dass ich es aufbewahre, ohne es jemals sehen zu können.)
In all den Szenarien, die ich mir ausgedacht habe, finde ich immer einen Weg, auf die Daten zuzugreifen. Lassen Sie mich einige von ihnen beschreiben.
Szenario I: Schränken Sie die Tabelle in der Live-Datenbank so ein, dass nur der SQL-Administrator direkt darauf zugreifen kann.
Hack 1: Rollout eine Änderung, die sendet die Daten in einer anderen Tabelle für die spätere Anzeige. Außerdem kann der SQL-Administrator die Daten sehen, wodurch die Anforderung aufgehoben wird.
Szenario II: Verschlüsseln Sie die Daten, sodass zum Entschlüsseln ein Kennwort erforderlich ist. Dieses Passwort ist nur den Benutzern bekannt. Es wäre jedes Mal erforderlich, wenn ein neuer Datensatz erstellt wird, sowie jedes Mal, wenn die Daten aus einem alten Datensatz abgerufen wurden. Die Verschlüsselung / Entschlüsselung würde in JavaScript passieren, so dass das Passwort nie an den Server gesendet würde, wo es protokolliert oder geschnüffelt werden könnte.
Hack II: Rollout eine Änderung, die Tastatureingaben in Javascript und sendet sie zurück an den Server, damit ich das Passwort abrufen kann. Oder führen Sie eine Änderung aus, bei der die unverschlüsselten Daten einfach in einem ausgeblendeten Feld gespeichert werden, das zur späteren Anzeige auf dem Server bereitgestellt werden kann.
Szenario III: Machen Sie dasselbe wie Szenario II, außer dass die Verschlüsselung / Entschlüsselung auf einer Website stattfindet, die wir nicht kontrollieren. Diese magische Website würde es einem Benutzer erlauben, ein Passwort und die verschlüsselten oder unverschlüsselten Daten einzugeben, und dann JavaScript verwenden, um diese Daten zu entschlüsseln oder zu verschlüsseln. Dann könnte der Benutzer einfach den verschlüsselten Text kopieren und ihn in das Feld für neue Datensätze einfügen. Sie müssten diese Seite auch benutzen, um den Klartext für alte Aufzeichnungen zu sehen.
Hack III: Neben der Installation eines vollwertigen Keyloggers auf ihrem System weiß ich nicht wie Brechen Sie diese.
Szenario III sieht vielversprechend aus, ist aber für die Benutzer umständlich. Gibt es andere Möglichkeiten, die ich übersehen kann?
Wenn Sie Javascript auf der Seite haben können, dann glaube ich nicht, dass Sie irgendetwas tun können. Wenn Sie es in einem Browser sehen können, bedeutet das, dass es im DOM ist, was bedeutet, dass Sie ein Skript schreiben können, um es zu bekommen und es nach der Entschlüsselung an Sie zu senden.
Werden diese Probleme normalerweise nicht über Steuerelemente gelöst:
Zum Beispiel - kein JavaScript auf der Seite ohne Abmeldung.
Wenn Sie einen beliebigen Code hinzufügen können, gibt es immer einen Weg, IMO.
Bitten Sie den Kunden, eine Geheimhaltungsvereinbarung für Sie zu unterschreiben, zu unterschreiben und sich so viele Daten anzusehen, wie Sie möchten.
Was ich mich wundere ist, was genau können Sie mit verschlüsselten Daten machen auf jeden Fall ? Pretty-viel alle Apps erfordern Sie einige Filterung der Daten, ob es an einen gewünschten Ort zu verschieben, zu ändern, zu bereinigen oder anzuzeigen. Sonst bist du nur eine verherrlichte Pfeife, und du musst keine Arbeit machen.
Der einzige Weg, an den ich denken könnte, wo Sie die Daten nicht ansehen oder etwas damit machen würden, wäre eine einfache Form der Tabellenzuordnung mit CRUD-Optionen. Wenn Sie wissen, in welches Format die Daten kommen sollen, sollten Sie in der Lage sein, etwas mit RoR, einem einfachen Skin, herauszubringen, SSL in den Mix zu integrieren und auszurollen. Testen Sie mit Dummy-Daten im selben Format, und Sie sind eingestellt.
Kann Ihr Kunde tatsächlich Dummy-Daten zum Testen bereitstellen? Wenn sie können, dann ist dein Leben einfach, da du nur ein "installierbares" zur Verfügung stellst und ihnen sagst, wie man eine Konfigurationsdatei bearbeitet.
Ich denke, du könntest die App trotzdem auf folgende Weise erstellen:
Natürlich ist die Pflege der App und das Debugging eine Schlampe!
- In Antwort auf Kommentare:
Ok, schreiben Sie nach dem Einrichten des Kennworts für den Benutzernamen in der Datenbank und in der Konfiguration der Webanwendung ein Programm, das eine Verbindung zur Datenbank herstellt, ein zufälliges Kennwort festlegt und das gleiche zufällige Kennwort in das Web schreibt Konfig.
Verhindern Sie alle ausgehenden Pakete von der Maschine, außer auf eine Gruppe autorisierter Arbeitsstationen - so können Sie Ihre Spyware nicht installieren.
Setzen Sie dann das Administratorpasswort auf beiden Servern auf das gleiche zufällige Passwort, löschen Sie dann alle anderen Benutzer auf den Servern, löschen Sie das Programm und löschen Sie den Programmquellcode.
Wischen Sie die Festplatten der Entwicklermaschinen mit dem DOD-Algorithmus ab und werfen Sie sie dann in einen Industrieshredder.
Aber im Ernst - das ist ein unlösbares Problem. Die beste Antwort darauf ist wirklich:
Sagen Sie ihnen, dass sie keine Anwendung haben können. Schreib deine Sachen auf Papier. Legen Sie es in einen Ordner. Lock es in einem Tresor. Schub, wiederhole.
Würde Szenario 3 nicht einfach alle Daten der magischen Website aussetzen? Das hört sich nicht nach einem lösbaren Problem an (zumindest kann ich mir keine Lösung vorstellen).
Ich muss sagen, dass mir die Idee, JavaScript auf dem Client zum Entschlüsseln der Daten zu verwenden, wirklich nicht gefällt. Das ist ein riesiges Loch, da jedes Skript (Hacker, GreaseMonkey, IE7Pro, etc.) auf das DOM zugreifen und Daten aus der Seite holen kann.
Außerdem ist es sehr schwierig, das Problem der Key-Stroke-Logger zu umgehen. Wenn Sie diese in den Mix werfen, sind Ihre Möglichkeiten begrenzt. An diesem Punkt benötigen Sie ein Sicherheits-FOB wie RSA (das häufig bei Unternehmens-VPNs verwendet wird), um wirklich zufällige PINs zu generieren. Das wird wahrscheinlich teuer, und es ist ein Schmerz, und ich habe es nur mit VPNs verwendet gesehen, aber ich nehme an, es könnte auch mit Websites funktionieren.
Was die Website betrifft, würde ich bei HTTPS bleiben und eine Möglichkeit finden, über den WebServer zu verschlüsseln / zu entschlüsseln, anstatt mich auf JavaScript zu verlassen. Der SSL-Verkehr ist nicht sehr anfällig für Sniffing (sehr schwer zu entschlüsseln), so dass die Verschlüsselung und Entschlüsselung serverseitig erfolgen kann, was (IMHO) sicherer ist.
Betrachten Sie Bankenszenarien und andere Finanzinstitute als Ausgangspunkt und gehen Sie dann von dort aus. Versuchen Sie, nicht zu komplizieren, wenn möglich.
Sie können nicht gegen das Eindringen in die Daten garantieren, solange Sie Zugriff auf den Server haben, auf dem es sich befindet. Sagen Sie dem Arbeitgeber, dass er die Daten irgendwo anders hosten muss und gewähren Sie ihm über eine sichere HTTPS-Verbindung Zugriff auf den Browser des Clients
.Sie können Ihre Webseite so gestalten, dass sie einen XML-Datenstrom dynamisch sicher lädt und mithilfe eines XSLT-Skripts auf dem Client in eine Webseite formatiert.
Siehe Ссылка für Beispiele
Auf diese Weise erzeugen Sie den Code, aber Sie haben nie Zugriff auf die Daten. Nur der Benutzer hat Zugriff auf seine eigenen Daten.
Wie der Arbeitgeber die Daten hostet, ohne dass IT-Mitarbeiter Zugang dazu haben, das ist ihr Problem. Es ist eine dumme Anforderung.
Ich denke, ich werde ihnen nur sagen, dass sie entweder einem Paar von uns vertrauen müssen, um Zugang zu haben (und es nicht anschauen), oder sie bekommen kein Projekt.
Danke für die Antworten. Fühlen Sie sich frei, weitere Gedanken zu posten, wenn Sie sie haben.
Sie können nie 100% Sicherheit haben, und zusätzliche Sicherheit kostet Kosten / Geschwindigkeit / Komfort / etc.
Nehmen wir an, Sie nehmen Szenario 3 - einer Ihrer Programmierer kann Social Engineering verwenden, um das Passwort von einem der Benutzer zu erhalten. Auf Wiedersehen Sicherheit.
Es hat keinen Sinn, eine Hochsicherheits-Eisentür als Tor zu haben, wenn die Leute einfach herumlaufen können. Implementieren Sie einfach ein anständiges Sicherheitsniveau.
(Sie wollen, dass ich es aufbewahre, ohne es jemals sehen zu können.)
Hey, die Musikindustrie möchte, dass die Leute ihre Musik hören, aber nicht kopieren können. Klingt, als sollten sie sich irgendwann treffen!
Ihre Idee wird aus dem gleichen Grund, warum DRM nicht funktioniert, nicht funktionieren: Die Vertrauenskette ist inhärent kompromittiert. Verschlüsselungsbeispiele verwenden oft Alice, Bob und Charlie, wo Alice versucht, mit Bob zu kommunizieren, ohne dass Charlie zuhört. Mit DRM ist die Vertrauenskette kompromittiert, weil Bob und Charlie die gleiche Person sind. In Ihrer Situation schreibt Charlie die Software, mit der Alice und Bob kommunizieren. Es gibt ein stillschweigendes Vertrauen, denn wenn Sie Charlie nicht vertrauen, können Sie Charlies Software auch nicht vertrauen.
Das ist die Wurzel des Problems: Vertrauen. Wenn sie dem Programmierer nicht vertrauen können, ist das Spiel beendet, bevor es beginnt.
Es gibt viele Optionen basierend auf dem, was ihr Ziel wirklich ist, aber ich bin verwirrt durch ihre Paranoia, äh, Absicht:
Planen sie eine gestaffelte Bereitstellung? In diesem Fall arbeiten Sie auf dem Test / Dev-Server ohne echte Daten, haben aber keinen Zugriff auf den Produktionsserver mit den echten Daten und die DNS-Protokollierung und / oder Firewall-Regeln verhindern, dass alle Ihre Hacks unbemerkt arbeiten.
Wenn die Daten letztendlich in einer Datenbank gespeichert sind, können der Programmierer und der DB-Administrator sie gemeinsam bearbeiten. Zeitraum. Ein gutes Audit sollte das jedoch aufdecken.
Wenn dies wirklich eine Anforderung ist, ist der einzige Weg, dagegen zu warnen, eine externe Firma zu beauftragen, den Code vor der Veröffentlichung der Software zu prüfen, und das wird sehr teuer.
Tags und Links database security encryption