Quali sono i privilegi ragionevoli per garantire gli utenti tipici? [chiuso]

Trovo che l' elenco dei privilegi forniti da MySQL sia un po 'travolgente. Non sono sicuro di chi dovrebbe avere quali privilegi. Nella mia mente ci sono tre utenti tipici per la mia situazione:

1. root
2. developer
3. application

rootsi spiega da sé. Per developerquesto utente deve essere in grado di accedere facilmente a qualsiasi database, apportare modifiche ad esso, ecc. Per cominciare sto impostando questo utente su questo set di privilegi:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationha un set ancora più limitato. Dovrebbe limitarsi a manipolare un database specifico.

Non sono sicuro di quale ragionevole insieme di privilegi sia concesso. Quali sono una serie ragionevole di privilegi per concedere uno sviluppatore e un'applicazione e perché?

Un utente tipico dovrebbe avere:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

I primi quattro sono abbastanza ovvi, anche se puoi anche impostare utenti di "sola lettura" con SELECT.

CREATE TEMPORARYè anche utile e generalmente innocuo: le tabelle temporanee possono aiutare a ottimizzare le query, suddividendole in parti più piccole e più veloci. Sono limitati alla connessione in esecuzione e vengono automaticamente eliminati quando viene chiuso.

EXECUTEdipende dal tipo di sistema. Hai routine memorizzate? Desideri che i tuoi utenti accedano a loro? Assicurati di conoscere anche la SECURITY=DEFINER/INVOKERdefinizione per le routine memorizzate.

In ogni caso, assicurati di applicare tutto quanto sopra su schemi specifici . Evitare di usare:

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

poiché quanto sopra concede anche privilegi sulle mysqltabelle di sistema, consentendo in modo efficace a qualsiasi utente di creare nuovi account o aggiornare il proprio set di privilegi. Invece, fai:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

In qualsiasi sistema su scala reale (cioè non un progetto personale) questi tipi di utenti variano a seconda dell'ambiente, quindi non è così semplice.

In tutti gli ambienti l'applicazione dovrebbe avere ciò di cui ha bisogno e non di più (in genere si tratta di "selezionare / inserire / aggiornare su tutte le tabelle" e "exec su tutte le procedure". Per i sistemi più grandi in cui è possibile avere utenti dell'applicazione separati per attività diverse (per ad esempio, un'applicazione è responsabile dell'alimentazione dei dati del censore e un'altra per la generazione di report) è necessario separare i propri privilegi in modo che abbiano il minimo necessario (l'utente del report probabilmente non ha bisogno e diritti di scrittura). Assicurarsi di replicarlo nel test ambienti se li hai: ho visto cadere il codice quando promosso a Live che funzionava in test perché tutto nell'ambiente di test accedeva al DB come sa(equivalente a MSSQL root).Idealmente, un utente dell'applicazione generalmente non dovrebbe avere privilegi che gli consentano di modificare lo schema (CREATE,, DROP...) - ci sono eccezioni a questo, ma sono poche e lontane tra loro.

rootè, beh root,. In produzione questo è solo il tuo DBA e dovrebbe essere usato raramente, solo per la manutenzione del sistema (aggiornamenti alla progettazione del DB e così via) e monitoraggio. Per un sistema di grandi dimensioni, specialmente in ambienti regolamentati in cui è necessario mantenere uno stretto controllo delle persone ai fini della responsabilità, è possibile che non si consenta affatto a un singolo rootutente e si provi a separare i privilegi in rotoli più piccoli (non sono sicuro di quanto si possa andare lontano con questo in mysql, ma puoi essere abbastanza ben preciso in MSSQL, Oracle e così via).

Per gli utenti degli sviluppatori: non dovrebbero avere alcun accesso ai tuoi ambienti live. Questo è uno dei motivi per cui gli utenti dell'applicazione non dovrebbero avere schemi che incidono sui diritti: qualcuno con accesso a un account sviluppatore potrebbe potenzialmente aggirare il loro blocco in questo modo. Anche negli ambienti di test di solito non hanno accesso: invieranno patch al QA e il DBA (probabilmente usando un rootutente) per il QA applicherebbe gli aggiornamenti all'ambiente di test (in realtà questo è spesso automatizzato in grandi organizzazioni, quindi il DBA del QA è in realtà un insieme di script che controlla la ricostruzione dell'ambiente di test per ciascun ciclo). Negli ambienti di sviluppo, specialmente se gli sviluppatori hanno le loro copie locali del servizio in esecuzione, questi utenti dovrebbero ovviamente avere pieno accesso a tutto per poter sperimentare.

Quanto sopra è tutte note generali: per formulare raccomandazioni specifiche dovremmo sapere molto di più sulle vostre applicazioni e sugli ambienti in cui operano. L'ambiente di destinazione a volte è più importante di quanto si possa pensare: a seconda dell'ambiente aziendale i diritti dei tuoi utenti potrebbero persino essere dettati in modo abbastanza diretto come norme legali, anche in fase di sviluppo se i tuoi clienti ti danno mai accesso a dati reali a fini diagnostici.