it-swarm-eu.dev

Měli by vývojáři dotazovat produkční databáze?

Měli by vývojáři dostat povolení k dotazování (SELECT/read only) produkčních databází? Na předchozím místě jsem pracoval, vývojový tým měl db_datareader role; kde nyní pracuji, vývojový tým se nemůže připojit ani k produkční instanci.

Jednou z testovacích instancí je kopie výroby obnovené ze zálohy výroby jednou týdně, takže vývojáři skutečně nevidí data, takže nejsou žádné problémy.

Jaké dobré důvody jsou pro to, že vývojářům neumožňují produkci dotazů (s výjimkou toho, že jednoduše nechtějí, aby měli přístup ke čtení citlivých dat)?

164
Tom Hunter

Skutečně záleží na tom, zda má vývojář nějaké povinnosti podpory. Pokud jsou na háku pro podporu třetího řádku, bude pravděpodobně nutné podívat se do produkční databáze, aby to udělali.

Obecně je špatný nápad dělat cokoli na produkčním serveru, ledaže by to tam opravdu bylo potřeba.

Pro většinu vývojových účelů budou zrcadla nebo snímky produkční databáze přiměřené a pravděpodobně lepší než živá produkční databáze. Pokud děláte něco, co zahrnuje integraci, budete chtít stabilní databázová prostředí, kde můžete ovládat, co v nich je. Vše, co zahrnuje usmíření, bude také vyžadovat schopnost podívat se na kontrolované místo v čase.

Pokud problém spočívá v tom, že nemáte prostředí produkčního zrcadla nebo žádné prostředky, aby někteří vývojáři umístili kopii produkčních dat, pak je to poněkud jiná otázka. V takovém případě vaši vývojáři skutečně potřebují alespoň jedno zrcadlové prostředí. Pokud nevidíte, v čem je problém v datech, je těžké jej vyřešit.

Ne.

Vývojáři by neměli mít přístup k produkčním databázovým systémům z následujících důvodů:

  1. Dostupnost a výkon : Mít práva pouze pro čtení k databázi není neškodná . Špatně napsaný dotaz může:

    1. Zamkněte tabulky, blokujte další kritické procesy.
    2. Vymažte mezipaměť dat a vynucujte další procesy, aby znovu načítaly data z disku.
    3. Zdaňujte vrstvu úložiště a ovlivněte tak další služby, které sdílejí dané úložiště.
  2. Zabezpečení : Vaše produkční databáze může obsahovat citlivé informace, jako například:

    • hashe hesla
    • fakturační údaje
    • další osobní údaje

    Měly by je mít pouze ti, kteří absolutně potřebují přístup k těmto informacím. V dobře organizované společnosti nejsou vývojáři mezi těmito lidmi. Kromě toho vaše společnost selže v souladu s PCI a SOX, pokud její vývojáři mají přístup k produkčním systémům s těmito daty

    Důvody jsou zřejmé. Vývojová práce vývojáře prochází mnoha rukama před tím, než začne fungovat. Co brání škodlivému vývojáři přímým výrobním přístupem v krádeži vašich produkčních dat nebo v přenesení vaší živé databáze na kolena?

    "Ale to platí i pro DBA! Mohli by to udělat!" Přesně. Chcete co nejméně superuživatelů, jak je to možné.

Ano.

Vývojáři by měli mít přístup k produkčním systémům.

V mé společnosti máme čtyři týmy, které se zabývají produkčními databázemi. Oni jsou:

  1. Vývojáři , kteří navrhují a zapisují schéma a kód pro databáze. Nemají přístup k databázím ve výrobě. Někdy však sedí s administrátory nebo podpůrnými lidmi a pomáhají jim podívat se na něco živého.
  2. Správci , kteří implementují, monitorují a spravují databáze ve výrobě.
  3. Podpořte lidi , kteří zkoumají výrobní problémy citlivé na čas a poskytují zpětnou vazbu vývojářům, aby mohli vyvíjet opravy.
  4. Lidé Business Intelligence , kteří extrahují data z produkčních databází pomocí pravidelně aktualizovaných kopií těchto databází nebo pečlivě psaných a QA-ed výpisů (obvykle navržených administrátory ).

Pokud máte určité nedostatky v těchto jiných skupinách, je vhodné udělit vývojářům přístup k produkci.

Například:

  • Nemáte žádný podpůrný tým. Kdo bude vědět, kde hledat, aby ladil tento časově citlivý výrobní problém? Vaši vývojáři. Udělte jim přístup " rozbijte sklo ".
  • Nemáte žádný tým BI. Vaši administrátoři nemají nebo nechtějí mít nic společného se zprávami nebo výpisy. Kdo bude řešit hlášení, které vaši popravčí vidí každé ráno? Vaši vývojáři. Poskytněte jim omezený přístup k ladění těchto zpráv a výpisů.
  • Nemáte žádný administrátorský tým. Jste ve velmi malé nebo začínající společnosti, takže pozdravte „náhodnou DBA“. Vaši vývojáři se jako administrátoři zdvojnásobí, a proto potřebují plný přístup k produkci.
136
Nick Chammas

Výkon by byl velkým důvodem.

To, že nemohou změnit data, neznamená, že nemohou ovlivnit server. Špatně napsaný dotaz by mohl přinést produkční prostředí na kolena a potenciálně způsobit další problémy (jako přetečení tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

To je recept na katastrofu. Všimněte si, že se jedná o kartézský produkt s objednávkou, což znamená, že bude seřazen v tempDB.

79
JNK

Princip je „nejméně privilegovaná“ a „potřeba vědět“: projdou vývojáři touto zkouškou?
Zvláště, když auditorové nebo Sarbannes-Oxley klepe.

Pak můj další předpoklad: vývojáři jsou hloupí. Takže pokud potřebují říci pro podporu 3. řádku, kdo pak to potřebuje? Web opice obvykle ne, ale typy databáze ano, pokud se očekává, že ji podporují.

Je tedy potřeba přístup trvale? Mohou mít přístup „rozbít sklo“ pomocí přihlašovacího jména SQL nebo alternativního účtu Windows, který vyžaduje odhlášení. V našem případě to byl vlastník dat (doufejme, že nějaký technický důvtipný podnikatel) a IT manažer to schválili.

viděl viděl vývojáře testovat nebo spouštět dotazy na produkci a snižovat kvůli nevědomosti. Řekli by, že vývojáři by měli převzít odpovědnost za své činy: pokud server zastaví, měli by podle toho trpět. Po jednom incidentu mě někdo degradoval ...

Předpokládají samozřejmě přiměřeně velký obchod. Čím více lidí nosí klobouky, tím menší oddělení povinností můžete mít

Existuje také prostředí, ve kterém mohou vývojáři spouštět dotazy na základě posledních dat? V mém posledním obchodě byl prod každou noc obnoven na testovací server, aby to poskytl.

33
gbn

Myslím, že odpověď zní, stejně jako u mnoha věcí IT, „záleží“.

Masivní databáze ERP=) se spoustou citlivých informací o společnosti a zákaznících? Pravděpodobně ne (z důvodů bezpečnosti i výkonu).

Oddělení databáze 5 MB s frontendem Access, který sleduje příspěvky do fondů koblihy a pizzy? Nebude to mít velký rozdíl, alespoň pro přístup jen pro čtení.

Je pravda, že první příklad je mnohem běžnější než druhý, ale jedná se o rozdíly, o kterých byste měli vědět, pokud máte na starosti tyto typy politických rozhodnutí. Na druhou stranu je úžasné, jak rychle může 5-fondová databáze pro koblihy a pizzu rozšířit svou cestu k 50 GB částečným číslům/číslům kreditních karet zákazníků/kdo ví, co- jinak databázi, pokud ji necháte.

20
db2

V obvyklém prostředí 24/7 OLTP) by běžný vývojář neměl být povolen ve výrobě. Ale obvykle ne.

Viděl jsem pro to mnoho důvodů:

  • VYBRAT * z velkého stolu vedoucího k:

    • problémy s výkonem (kartézské výrobky);
    • blokování problémů, které nakonec přivedly web na kolena;
    • blokovací řetězec, který zastavil replikaci;
    • objednání velké sady dat, která naplnila jednotku TempDB, která .. hádejte co? Způsobil úplné šílenství :-)!
    • vysoký krevní tlak pro DBA, který má na starosti produkci té noci;
  • čtení citlivých dat (vývojář by neměl mít přístup k informacím o kreditní kartě.

Jsem si jist, že existuje ještě více důvodů.

20
Marian
  • Zabezpečení: Mohou existovat citlivé informace, které jsou dezinfikovány, když je zpřístupní vývojářům.
  • Paranoia: Někteří si mohou myslet, že byste si mohli dát data jen tak, že si vyberete přístup.
  • Výkon: Dotaz vyžaduje několik zdrojů, a nemůžete mi říct, že jsou vývojáři dokonalí, když píšou kód.
19
Paul

Několik věcí, které je třeba zvážit

  • Jsou data citlivá?
  • Jsou programátoři součástí důvěryhodného týmu nebo nějakého offshore týmu?
  • Jaký je rozsah dotazovaných dat, pokud jde o dopad na výkon?
  • Jaký je rozsah projektu nebo dolarů?
  • Jak kritická je doba provozu?

Menší dolary potřebuje méně procesu, potřebuje rychlejší tok vývoje.

Větší dolary potřebuje více procesu, vyžaduje přísnější standardy vývojových postupů.

Přizpůsobte své postupy tomu, co děláte.

16
Jason Sebring

Pracuji jako vývojář pro velmi velkou společnost. Všichni naši vývojáři, kteří budou poskytovat jakoukoli podporu (v podstatě všichni), mají přístup k relevantním výrobním databázím. Můžu mluvit pouze za svůj konkrétní tým, ale řeknu vám, proč my mít přístup.

  1. Potřebujeme přístup v reálném čase, abychom mohli sledovat naše každodenní zpracování. (I když máme řídicí panel, musíme být schopni dohlížet na věci. I když by bylo hezké mít tuto funkci na našem dashboardu, zjistili jsme, že to není praktické.)
  2. Potřebujeme přístup v reálném čase, abychom mohli zjistit případné výpadky výroby, protože zpoždění může mít obrovský dopad. (Nebudu zde hovořit o našich neúspěchech. Přicházejí nejrůznějšími způsoby)
  3. Často potřebujeme vytvářet vlastní přehledy pro firemní uživatele a tyto informace musí být aktuální. (dba to nemá čas na to a my nemáme čas na ně čekat. I když není ideální, určitě.)
  4. Musíme provést ověření produkčních nasazení/oprav DDL/DML. (DBA je nasadí, ale pouze víme, jak by měla být strukturována. Víme více o naší databázové struktuře než DBA. Možná bychom zde byli divní, ale z databáze je velmi komplikovaná, protože naše podnikání je velmi komplikované.)

Výkon je problém. Došlo k výskytu vývojářů způsobujících zpomalení. Jedná se však o izolované případy a naše SQL je tak výkonné, že je vzácné, že naši vývojáři nerozumí dopadům jejich dotazů.

14
user606723

Pro položení této otázky je třeba předpokládat, že v současné době nemají přístup. Pokud organizace vyvíjí software a jedná se o řešení problémů se zákazníkem a zákazník poskytne kopii své databáze, pak „ano“. Jinak bych se zasazoval o to, aby vývojáři nebyli z výroby a aby byla vytvořena alternativní prostředí pro jejich výzkumné potřeby. Jakmile je zubní pasta vytažena z tuby, je těžké ji zasunout zpět.

11
jl01

Souhlasím s tím, že ospravedlnění by mělo nést to, kdo vyžaduje přístup. Obvykle jsem měl v prostředích, kde jsem konzultoval, přístup k výrobním systémům, kde to bylo malé prostředí a byl jsem podpůrnou osobou. Měl jsem přístup k zálohám atd., Kde jsem podporu podporoval, a nepřímý přístup (prostřednictvím specializovaného vývojáře podpory) k výrobním datům.

Velká věc je: Tento přístup potřebujete, když jste na háku, aby vše fungovalo hladce, a musíte odpovědět na otázku finančníka o něčem, co nefunguje. V takovém případě nemůžete vždy pracovat ani z denních dat. Na druhé straně, čím více přístupu, tím horší to je. Obvykle jako konzultant mám tendenci se vyhýbat získávání tohoto druhu přístupu, pokud to není nutné. Protože pracuji na finančních databázích, poslední věcí, kterou chci, je obvinění ze zadávání vlastních faktur :-D.

Na druhou stranu, pokud nepotřebujete přístup, neměli byste jej mít. Opravdu si nekoupím argument citlivých dat, protože vývojář je pravděpodobně na háku, aby se ujistil, že se s ním zachází správně (a je velmi obtížné jej ověřit, aniž bychom se podívali na to, co bylo skutečně uloženo, když se objeví hlášení o chybě). Pokud vývojáři nemůžete důvěřovat, aby se podíval na data, která aplikace pro vývojáře ukládá, neměli byste vývojáři najmout, aby aplikaci napsal. Existuje příliš mnoho způsobů, jak by vývojář mohl data zatemnit a odeslat je e-mailem, a nikdy si nebudete jisti. Ovládací prvky MAC zde pomáhají, ale je stále velmi obtížné je implementovat.

Velký problém z mé strany souvisí s přístupem k zápisu. Pokud tedy vývojář nemá přístup, a fortiori, vývojář nemá přístup pro zápis. Pokud chcete ověřit integritu knih, chcete zachovat přístup k zápisu pro co nejméně lidí. Auditní stezky lze mnohem snáze ověřit, pokud vývojáři nemají přístup. Pokud vývojář má přístup ke čtení, máte vždy nějakou otázku, zda došlo k nějakému připojení oprávnění, které může poskytnout přístup pro zápis (možná injekce SQL do uložené procedury?). Když jsem měl přístup k pracovním prostředím, často jsem měl plný přístup k fakturačním informacím klienta. Pokud však funguje pracovní prostředí, obvykle aktivně požádám nikoli o přístup k produkci, pokud to není nutné.

Takže to samozřejmě není dokonalé. Vývojář by mohl do aplikace zabudovat zadní dveře, které nemusí být snadno detekovatelné, ale tento přístup je rozumný, vzhledem k tomu, že záložní data jsou k dispozici den před tím se mi zdá, že se jedná o problém, který mají.

Snad to pomůže.

Úpravy: Jen jsem dodal, že ve větších prostředích, ve kterých jsem pracoval, jsem měl přístup k úplným zálohovacím datům, často pro finanční systém, od několika dnů až po několik měsíců. To bylo vždy pro moji práci dost dobré a jediné, co se rozpadlo, bylo, když finanční kluci potřebovali schopnost testovat s novějšími daty, aby se mohli srovnávat s produkcí.

10
Chris Travers

Nemít přístup je dobrá věc a způsob, jak chránit vývojáře a ostatní před náhodným poškozením nebo prohlížením dat. To také chrání společnosti před porušováním zákona (tj. Porušení zákona a obavy o ochranu soukromí)

Vývojář nikdy nepotřebuje přístup k produkčnímu prostředí, z pohledu vývojářů je to jednodušší, pokud nelze reprodukovat těžkou chybu.

Vývojář však může vložit mini výpisy nebo protokolové soubory a pomocí souborů symbolů PDB znovu vytvořit chybu.

Pokud je třeba data přenést do testovacího prostředí, pak je typické, že nějaký proces vymytí data, která mohou vytvořit další práci.

V závislosti na databázovém softwaru, který se používá v produkci, které voláte, by mohla být pro vývojáře vyžadována nová licence pro přístup k databázi, což je velké náklady na prostý přístup ke čtení.

Pokud vám vaše společnost neposkytuje nástroje pro ladění nebo výzkum výrobních problémů, není to proto, že nemáte přístup k výrobním datům.

Data jsou nejcennější součástí většiny aplikací!

9

Výkon může být jedním z důvodů.

Dotazy vývojářů mohou být často neúčinné a způsobují nadměrné uzamčení nebo využití prostředků, dokud nejsou správně naladěny.

Produkční systém není pro vývojáře vhodným místem k experimentování.

8
JSR

Závisí to na DBA a na tom, jak si je jistý s vývojářem. Vývojářům jsou obvykle přidělena oprávnění pro čtení (čtení) do produkčních databází. Obecně platí, že vývojáři měli pracovat pouze s databázemi test/dev.

8
MarlonRibunal

Výzvou je, že většina softwarových aplikací je řízena daty. Takže když se pokoušíte vyřešit problém v aplikaci, musíte skutečně vidět data, která ji řídí. Vývojáři tedy potřebují určitou formu přístupu.

Použití přihlašovacích údajů SQL pouze k tomu, aby jim byl umožněn přístup pouze ke čtení, je skvělý. VUT v Brně, co jim znemožňuje vytvořit dotaz s 20 spojeními nebo dělat SELECT * z tabulky s miliony záznamů? Tyto dotazy mohou náhodně zabít výkon vaší databáze a úložiště.

Moje společnost Stackify přišla s chytrým způsobem, jak to vyřešit. Vývojáři mohou dotaz spouštět pomocí našeho softwaru a pomocí plánu dotazů se ujistíme, že se jedná pouze o příkaz SELECT a že odhadované náklady na dotaz jsou nízké a vrátí jen několik záznamů. Tímto způsobem nemohou ublížit. Auditujeme také všechny dotazy, které spouští.

To je jen jedna z věcí, které poskytujeme. Podívejte se na nás na http://www.Stackify.com , kde se dozvíte více o našich podpora DevOps řešení.

8

Ano. V některých případech má smysl povolit určité podskupině uživatelů, včetně vývojářů, určitou úroveň přístupu k datům o produkci dotazů. Správná omezení však musí existovat ze dvou důvodů. Za prvé, jako DBA musíte udělat vše pro to, abyste zajistili úroveň služeb, kterou potřebují všichni uživatelé. Také chcete zabránit neúmyslným špatným dotazům, jako jsou hromadné mazání nebo vilolace obchodních pravidel. Mělo by být samozřejmé, že musí být zavedeny řádné bezpečnostní kontroly.

Ať už máte jakékoli důvody, proč nepovolujete dotazy ad hoc přímo do databázových tabulek, může existovat případ umožňující dotazy prohlížet a ukládat procedury. Pomocí databázových oprávnění můžete přímo zabránit SELECT dotazy proti tabulkám a dokonce omezit, ke kterým pohledům a uloženým procedurám má daný uživatel přístup. Tato metoda nejenže poskytuje flexibilitu vaší uživatelské základně, ale také chrání integritu a realitu vašich dat při správné implementaci.

7
Tom Resing

V naší společnosti udržujeme otroky produkčních databází jen pro čtení, na které se výrobní služby nespoléhají. Poskytujeme vývojářům přístup k těm, kteří mají přístup k výrobním datům. Pokud existují citlivá data (informace o zákazníkovi, informace o platbě atd.), Omezíme replikaci těchto tabulek a udržujeme ukázkovou datovou tabulku na slave serveru.

5
Ryan Waldron

Ne, nikdy!!

Proto máme vývojové/testovací/UAT servery. Data z výroby mohou být zkopírována do testovacího prostředí a vývojáři mohou s testováním pokračovat. Vybrané dotazy mohou být také velmi škodlivé v případě produkčního prostředí. Zvyšuje zatížení a ve špičce může snížit celý výkon.

Jakékoli informace, které potřebují, by měly projít přes DBA, kteří mohou spustit to, co chtějí (Vybrat) a odeslat jim výsledky. Takto to děláme v našem prostředí.

1