176 messaggi dal 20 novembre 2014
Ciao a tutti,
ho modo con sql server di impedire il drop delle tabelle di un database ma al contempo permettere la modifica e cancellazione dati?
Grazie anticipate
salve,
questo si fa "normalmente" con i privilegi concessi al database user (https://msdn.microsoft.com/it-it/library/ms188371.aspx)...
si autorizza cioe'
GRANT DELETE ON [schema].[Tabella] TO [Database_Role/Database_User];

in quanto "nessuno" e' di base autorizzato a fare niente in un database, tanto meno a cancellare tabelle, a meno che, ovviamente e purtroppo, l'utente interattivo non sia un dbo...
in che situazione sei?
saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
176 messaggi dal 20 novembre 2014
Ciao,
l'ho creato come db_owner, ma ho provato anche a lasciarlo solo come public e dare i permessi delete e alter che mi servono, il problema è che abilitato l'alter si abilita anche il drop che è l'unica azione che voglio negare
salve,
a chi vuoi negare il permesso?
saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
176 messaggi dal 20 novembre 2014
Vorrei che l'utente che accede tramite il software che ha il permesso di leggere e scrivere sul db possa fare qualsiasi tipo di lettura/scrittura tranne il drop delle tabelle/database
salve....
allora.... siccome non capisco bene la situazione, partiamo da una premessa... la gestione della sicurezza in SQL Server...
Nei casi "normali", la normale protezione dei dati viene comunque affidate alle politiche standard di accesso ai dati, che consistono, in parole molto povere, in tre fasi distinte. la prima fase e' relativa all'autenticazione di connessione, dove e' quindi necessario essere autorizzati (tramite connessioni trusted gestite dal domain controller previsto nella rete in accordo con SQL Server, oppure con connessioni "standard" fornendo "nome utente" e "password") ad usufruire dei servizi esposti dal server stesso e quindi a connettersi... la seconda fase riguarda la possibilita', per chi si sia connesso, di accedere agli specifici database interessanti, operazione che viene eseguita associando un database user (per ogni database coinvolto) alla login di accesso al server... la fase finale riguarda, con diversi livelli di granularita', l'accesso ai singoli oggetti, siano essi tabelle, viste, stored procedures... a livello di tabelle e viste e' possibile scalare la granularita' garantendo a determinati utenti l'accesso in lettura, lettura/scrittura, anche a livello di singola colonna, vietando ad esempio a tutti "gli studenti" di poter accedere alla colonna "voto" della tabella [Students], pur consentendo loro di vedere ed eventualmente modificare la propria residenza anagrafica... questa operazione viene eseguita con apposite istruzioni di GRANT di accesso all'oggetto specifico...
di "base", qualsiasi nuova login (che non sia membro di ruoli a livello di server con privilegi amministrativi) non ha accesso a database, ed e' necessario risolvere la 2nda fase della procedura autorizzativa... una volta garantito l'accesso ai database interessanti, nessun privilegio a livello di oggetto e' ancora garantito (sempre che l'utente non sia membro di ruoli amministrativi a livello di database) e quindi non potra' accedere ne' agli oggetti, ne' tantomeno ai dati in essi contenuti), e quindi e' necessario risolvere la 3za fase della procedura amministrativa...
quindi, di base, nessun utente interattivo puo' accedere ai dati ne', tanto meno ed ovviamente, puo' cancellare una tabella...
cio' puo' avvenire solo se l'utente interattivo sia membro di ruoli amministrativi, che possa per cui creare/modificare/eliminare oggetti...
se questo e' il caso, cioe' i tuoi utenti sono database owners, ti trovi davanti ad un problema serio... hai in effetti bypassato la protezione di SQL server, e questo NON SI FA MAI :)
nel tuo caso specifico, se l'utente interattivo e' un utente "tradizionale standard" (senza privilegi amministrativi) ed hai garantito l'accesso ai dati (secondo me comunque sbagliato e mi esprimero' poi in merito), quindi hai eseguito le istruzioni di autorizzazione
GRANT SELECT, UPDATE, INSERT, DELETE ON [schema].[Tabella] TO [Database_Role/Database_User];
dovresti essere a posto, in quanto questi NON potra' eseguire istruzioni DDL di DROP...
in questo senso, un consiglio personale e' di creare ruoli di database specifici in base alle autorizzazioni che vorrai dare, quindi, ad esempio

1) Ruolo_SOLO_Lettura, del quale saranno membri tutti gli utenti che potranno SOLO leggere le tabelle interessanti
2) Ruolo_COMLPETO, del quale saranno membri tutti gli utenti che potranno anche modificare i dati delle tabelle interessanti

e questo con granularita' di tipologie... queste tipologie dovrebbero essere membro di schemi diversi:
tornando ad un esempio "scolastico",
1) schema_Amministrativo, dove ad esempio ci saranno le tabelle amministrative dell'azienda, ma anche le anagrafiche studenti
2) Schema_Scolastico, dove ci saranno le tabelle delle lezioni, dei voti, etc

avrai quindi un Ruolo
1) Amministrativo, del quale faranno parte gli utenti "contabili"
2) Professori, che potranno accedere e definire le lezioni, oltre che dare i voti, ma non potranno accedere ai salari
3) Studenti, che potranno "vedere" le lezioni e "vedere" i voti, ma potranno modificare la propria anagrafica per la parte email e telefono (ma non altre proprieta' della propria anagrafica)

potrai quindi
GRANT SELECT, UPDATE, INSERT, DELETE ON [schema_Amministrativo].[TabellaSalari] TO [Amministrativo];
GRANT SELECT, UPDATE, INSERT, DELETE ON [Schema_Scolastico].[TabellaLezioni] TO [Professori];
GRANT SELECT, UPDATE, INSERT, DELETE ON [Schema_Scolastico].[TabellaVoti] TO [Professori];

GRANT SELECT ON [Schema_Scolastico].[TabellaLezioni] TO [Studenti];
GRANT SELECT ON [Schema_Scolastico].[TabellaVoti] TO [Studenti];

GRANT EXEC ON [schema_Amministrativo].[storedProcedure_AggiornaStudenteSoloMieiDati] TO [Studenti];

il paradigma e' sempre concedere le minori autorizzazioni possibili...
in questo senso, e torno a quando dicevo "(secondo me comunque sbagliato e mi esprimero' poi in merito)", l'accesso ai dati va consentito SOLO tramite stored procedures, dove puoi meglio filtrare COSA ad esempio mostrare o aggiornare...
nel caso degli Studenti, abbiamo detto che questi possano variare SOLO telefono e email e solo della propria anagrafica, quindi NON possono vedere/modifica i dati di altri...
la stored procedure relativa ovviamente scende a granularita' di riga, e non di tabella...
e questa architettura previene anche l'esecuzione di codice SQL dinamico "maligno"...
qui pero' stiamo andando parecchio oltre :)

tornando a noi, SE E SOLO SE i tuoi utenti sono utenti standard interattivi senza particolari autorizzazioni, la gestione normale della sicurezza e' la strada (normale e tradizionale) da seguire...

SE, invece e purtroppo, utilizzi un approccio con un solo utente amministrativo (di SQL Server) tipo un Application Role (https://msdn.microsoft.com/en-us/library/bb669062(v=vs.110).aspx, https://voiceofthedba.com/2012/11/26/how-application-roles-work-in-sql-server/) o implementazioni similari, sei nei problemi...
questo tipo di implementazione prevede che un "utente" amministrativo sia utilizzato per qualsiasi tipo di operazione, quindi sia accesso interattivo tradizionale ai dati, CHE (putroppo) attivita' amministrative e quindi anche operazioni DDL

se (di nuovo, putroppo) ti trovi in questa circostanza, ti puoi solo un po' appoggiare su DDL TRIGGER, trigger che operano a livello di oggetto, https://technet.microsoft.com/en-us/library/ms175941(v=sql.105).aspx, e quindi ad esempio filtrare le operazioni di DROP TABLE, https://www.sqlservercentral.com/Forums/Topic1141863-338-1.aspx
MA, se l'utente puo' fare "quello che vuole", alla fine trovera' ovviamente anche il modo di disabilitare il trigger...

salutoni

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
176 messaggi dal 20 novembre 2014
Ciao e grazie per la tua risposta,
purtroppo mi ritrovo nell'ultimo caso per cui come ho spulciato in rete e mi confermi tu dovrò creare un trigger se voglio gestire questa cosa.

Grazie ancora
salve,
clr4633 ha scritto:
Vorrei che l'utente che accede tramite il software che ha il permesso di leggere e scrivere sul db possa fare qualsiasi tipo di lettura/scrittura tranne il drop delle tabelle/database


mi fa comunque "specie" la richiesta... SE l'utente si connette al database solo tramite il tuo applicativo, tecnicamente NON dovrebbe poter inoltrare richieste DDL... sara' comunque l'applicativo a gestire le sole transazioni con la base dati, che solitamente NON contengono attivita' DDL ma solo DML, quindi INSERT/UPDATE/DELETE...
continuo a non capire...
salutoni

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.