Proteggi Database Design - SQL

Question

Proteggi Database Design - SQL

#1 da (5 voti)
#2 da (3 voti)
#3 da (1 voti)

1

Forse una domanda un po 'strana, ma non riesco a pensare a un modo per ottenere ciò che voglio.

Produco un prodotto che finisce installato sul posto presso i clienti. È un'applicazione business critical e ad alta disponibilità e deve gestire i processi molto rapidamente.

Sebbene ovviamente la maggior parte del lavoro vada nella reale applicazione (Servizi Windows) parte del motivo per cui il prodotto è così buono è la progettazione intelligente del database.

Fino a poco tempo fa solitamente fornivo i server e ero l'unica persona ad avere accesso al database e all'istanza di SQL Server. Tuttavia, più di recente i clienti hanno chiesto di eseguire l'applicazione sul loro server di produzione, di solito VMWare, e di utilizzare la loro SQL Farm per il database.

Questo va bene per l'applicazione, tuttavia sono preoccupato per chi avrà accesso al server SQL e se sarebbe in grado di dare un'occhiata nel database della mia applicazione.

C'è qualcosa che posso fare per impedirne l'accesso? O è un caso se lo stanno ospitando non c'è nulla che io possa fare?

Grazie

EDIT:

Se vengo investito da un autobus, la compagnia piega, ecc. c'è un accordo di deposito a garanzia che fornirà loro il codice sorgente di tutto ciò di cui hanno bisogno.

Riguardo al motivo per cui sono preoccupato, ho visto esempi in passato di persone che hanno apportato modifiche a tabelle e report di dati, e no non avevano il coraggio di farlo. Ciò significava che qualcuno doveva entrare e aggiustare tutto, mentre ovviamente chiedevamo questo perché mi chiedevo se c'era un modo per evitarlo tutto insieme, o almeno minimizzare il rischio.

sql intellectual-property

posta Nick Williams 17.05.2013 - 16:47

fonte

3 risposte

Leggi altre domande sui tag sql intellectual-property

Devo includere la nota sul copyright dell'autore originale? È legittimo chiedere ai colleghi di utilizzare un browser specifico in un sito Web intranet?

score 5 · Answer 1

È perfettamente ragionevole che un cliente aziendale preferisca ospitare l'applicazione internamente. Permette loro di stabilire lo standard per l'accesso diretto ai dati, per i backup, per sopravvivere al tuo eventuale decesso, ecc. Un'azienda dovrebbe essere preoccupata se una persona su cui non hanno supervisione e per chi non ha controlli di sostituzione qualcosa che è fondamentale per la loro attività. Che cosa succede se vieni colpito da un autobus?

Per attenuarlo, sono stati inventati i contratti. Puoi firmare un nuovo contratto con loro, che (per esempio)

Concede loro una copia del codice sorgente.
Concede loro il permesso di eseguire un'istanza dell'applicazione per la loro attività.
Concede loro il permesso di modificare l'applicazione per la loro attività.
Non autorizza il rilascio del codice sorgente e specifica le sanzioni.
nega il permesso di derivare nuove applicazioni dal codice sorgente e specifica sanzioni.
Absolves di qualsiasi responsabilità per la correzione delle loro modifiche al codice sorgente.
Absolves di qualsiasi responsabilità per l'integrazione di modifiche alla tua versione del codice sorgente e la loro versione del codice sorgente; è necessario solo fornire loro il codice sorgente che produce l'applicazione ospitata per altri client.

Dovresti vedere un avvocato su cosa dovrebbe essere incluso in qualsiasi contratto, io non sono un avvocato.

score 3 · Answer 2

I principali software player, Oracle, SAP, ACI, Sunguard ecc. ecc. hanno tutti i migliori prodotti di vendita dotati di un database relazionale. Nessuno di essi si sforza di nascondere o offuscare lo schema del database.

Inoltre, molti clienti per le app mission critical richiederanno una copia del codice sorgente, come assicurazione che possono far funzionare il sistema in caso di fallimento o essere trasferiti da Computer Associates.

Quindi perché rischiare di alienare i tuoi (ex-) clienti che, dopo tutto, non sono interessati a scrivere il proprio software o non sarebbero interessati ad acquistare i tuoi.

Va notato che i database forniti dai clienti sopra citati sono molto difficili da decifrare - ma questo è dovuto al fatto che il livello di astrazione richiesto per rendere flessibile il prodotto porta a un sacco di riferimenti indiretti nei loro progetti di database (cioè piuttosto di una colonna cust_name in una tabella customer hanno una colonna cust_name_location che si riferisce alla colonna ref256 in ip_ref_table )

score 1 · Answer 3

Se lo ospitano su un hardware a cui hanno accesso root, nella loro copia di un programma di database, non puoi impedire loro di accedere al design del tuo database. Nella migliore delle ipotesi, potresti aggiungere un livello di offuscamento al codice, come scrivere un programma per rinominare tutte le tabelle e i campi e le variabili interne e tentare di scrub il contenuto di "Testo SQL" di alcune tabelle di sistema.

Se non ti fidi molto dei tuoi clienti, puoi richiedere che il software venga eseguito solo sull'hardware che gestisci e quindi potrai gestire la loro server farm SQL interna. Il che potrebbe comportare che ti stiano dando calci al marciapiede a prescindere.

(La risposta migliore è "non ti preoccupare", e disponi di un programma di installazione che controlla le modifiche per proteggerti dal supportare le alternative di qualcun altro e un accordo di licenza che protegge i tuoi diritti se provano e prendono il tuo lavoro e vendono come loro.)