it-swarm-eu.dev

Rizika udělení vývojářům administrátorských práv na jejich vlastní počítače

Potřebuji přesvědčit své interní oddělení IT, aby svému novému týmu vývojářů udělila administrátorská práva k našim vlastním počítačům. Zdá se, že si myslí, že to vytvoří určité bezpečnostní riziko pro síť. Může někdo vysvětlit, proč by to mělo být? Jaká jsou rizika? Co IT oddělení obvykle nastavují pro vývojáře, kteří potřebují schopnost instalovat software do svých počítačů.

Tato otázka byla IT bezpečnostní otázka týdne.
Přečtěte si 8. června 2012 položka blog pro více informací nebo zadejte svůj vlastní Otázka týdne.

78
carolineggordon

Na každém místě, kde jsem pracoval (jako smluvní vývojář), mají vývojáři na svých stolních počítačích přidělena práva místního správce.

Důvody jsou:

1) Vývojářské sady nástrojů jsou často aktualizovány velmi pravidelně. Grafické knihovny, pomocníci s kódem, aktualizace vizuálních studií; skončí s aktualizací, která vychází téměř každý týden a je třeba ji nainstalovat. Podpora stolních počítačů je obvykle velmi unavená tím, že každý týden získává 20 vstupenek na instalaci aktualizovaného softwaru na všech počítačích dev, takže pouze dají administrátorským právům devs to udělat sami.

2) Nástroje pro ladění/testování někdy potřebují administrátorská práva, aby mohli fungovat. Žádný přístup správce znamená, že vývojáři nemohou dělat svou práci s ladícím kódem. Manažerům se to nelíbí.

3) Vývojář má tendenci si více uvědomovat zabezpečení, takže je méně pravděpodobné, že bude spuštěn/nainstalován nebezpečný malware. Očividně se to stále děje, ale všem vývojářům lze obvykle věřit, že mají přístup na vyšší úrovni, aby mohli vykonávat svou práci.

63
Alan Barber

To částečně závisí na druhu softwaru, který se od vývojového týmu očekává. Některé typy softwaru se snadněji vyvíjejí bez administrátorských práv než jiné.

Například můžete udělat značné množství webového vývoje Java vývoj pomocí typu Eclipse s artefakty Maven, všechny nainstalovány lokálně (a obvykle testovány na portu 8080), aniž byste potřebovali mnoho administrátorských práv (Možná budete muset otevřít určité porty.) Vývoj nástrojů, které vyžadují bližší přístup k hardwaru, se může ukázat jako nemožný bez administrátorských práv. Říká se to, že i pro vývoj webových stránek je dobrou praxí znovu vytvořit testovací stroj od nuly ( obvykle VM), což může vyžadovat administrátorská práva.

Pokud jde o důvěru (tj. Někteří členové vašeho týmu dev by mohli mít škodlivé úmysly), máte stejně potíže. Je nepravděpodobné, že by administrátoři, kteří by schválili/neschválili určitá práva, mohli podrobně zkontrolovat, jaký kód napsal. To také neznamená, že byste měli dát svému dev týmu neomezený přístup k vašim produkčním službám, ani že by měli mít administrátorský přístup na více strojích, než potřebují, samozřejmě. Je dobré mít zavedené mechanismy ke zmírnění rizik, ale pro fungování vaší organizace budete potřebovat určitou základní úroveň důvěry. Umístění dev týmu na samostatnou fyzickou síť je prvním krokem ke zmírnění problémů s důvěrou a možných chyb.

Typickým rizikem, že někdo s přístupem pro správce má schopnost zachytit pakety v síti. To je riziko, které budete možná muset přijmout v závislosti na povaze toho, co se vyvinulo. Nástroje jako Wireshark mohou být někdy užitečné pro vývoj. I ve vaší organizaci by měli IT nebo non-IT lidé používat služby s povoleným SSL/TLS, pokud je to možné, mělo by to pomoci proti odposloucháváním a útokům MITM.

Dokud neumím devs admin přístup (pokud to opravdu nepotřebují):

  • Může vytvořit kulturu „them v.s. us“ mezi devs a sysadminy ve vaší organizaci. To již existuje na mnoha místech, ale obecně to není dobrá věc. Každý tým bude pravděpodobně považovat ten druhý za bolest. Bezpečnost není čistě technickým problémem, nýbrž i problémem lidské interakce. Myslím, že dobrá lidská komunikace by měla pomoci celkovým cílům vaší organizace obecně, a to nejen z bezpečnostního hlediska. (Vždycky jsem zjistil, že dokážu najít lepší řešení po mluvit osobně k sysadminům, se kterými jsem potřeboval řešit problémy, spíše než odpovídat na anonymní lístek.)

  • Lidská povaha je taková, že lidé jsou kreativní, když jsou omezeni, ale ne nutně správným způsobem. Možná zjistíte, že devs vyvinou značné úsilí (a často uspějí) v obcházení omezení, která jsou jim uložena v organizaci. Měli by místo toho používat svou kreativitu k tomu, co mají dělat.

  • IT systémy jsou složité a ladění je temné umění. Pokud potřebujete ladit svůj produkt proti knihovně XYZ verze a.b.c_13 a a.b.c_24, může být nutné, aby vývojáři mohli nainstalovat a odinstalovat každou verzi, což může zase vyžadovat přístup správce. Pronásledování chyb, které závisí na číslech verzí, je již nepříjemné. Pokud musíte zvýšit vstupenku a čekat (možná hodiny nebo dny), než někdo jiný nainstaluje/odinstaluje správnou verzi, stane se z ní noční můra: zvýší kulturní problém „oni vs. nás“ a co je důležitější, bude to stát více do organizace. Můžete si to představit z pohledu posouzení rizika/nákladů.

28
Bruno

Riziko je rostoucí funkcí přístupu

Existuje jednoduché pravidlo pro výpočet rizika, které vysvětluje strach vašich kolegů z IT týmu. Čím více přístupu máte v kterémkoli operačním systému, tím vyšší jsou dopady jakékoli chyby nebo útoku.
Pokud například jeden z vašich kolegů, řekněme Bob, je napaden standardním phishingovým útokem, pak je Bobův účet k dispozici kybernetickým zločincům a prodán na internetu během několika minut. Pokud má účet Bob administrátorská práva, bude tento účet použit k odesílání nevyžádané pošty ve velkém měřítku na internetu, k odcizení dalších účtů s phishingovými útoky ve velkém měřítku a velmi rychle (během několika minut) otevře vaše dveře zadním dveřím síť (to je možné, protože účet Bob je administrátorský) umožňující úplné dálkové ovládání Bobova počítače (pomocí nástrojů jako ssh, VNC, VPN...) . Tento útok iniciovaný z interního počítače, z privilegovaného účtu, je schopen rozbít jakýkoli firewall, zastavit jakoukoli antivirovou a antispamovou ochranu.

Zlo je uvnitř.

Dokonce i vaši nejlepší síťoví administrátoři, systémoví administrátoři nebo bezpečnostní administrátoři mohou toto poškozené PC nechat celé měsíce neporušené (srov. Stuxnet).

Falešné snížení rizika

Pokud vaši vývojoví kolegové dobře spravují operační systém, na kterém pracují, a mají fyzický přístup k počítači, je tento rozdíl v riziku nulový.

Každý inženýr na jakémkoli OS
si může udělit administrátorský přístup
, pokud má fyzický přístup k počítači.

Blokování přístupu správce v jakémkoli OS je platný přístup ke snižování rizik pro uživatele, kteří nejsou schopni rozlišovat mezi oprávněními správce a běžnými oprávněními uživatele. Zde je klíčová otázka, kterou bych chtěl položit vašim spolupracovníkům vývojového týmu a jednat podle jejich povědomí o riziku:

"Na co se postaráte, pokud vám bude uděleno."
oprávnění správce ve vašem operačním systému? "

Jsou-li dostatečně dobří, aby si byli vědomi rizika, jsou dostatečně dobří, aby získali přístup, jaký chtějí. Pak není žádné snížení rizika, pokud by jim byl tento přístup správce odmítnut. Dejte si pozor: existuje riziko pro vaši společnost jako celek, pokud jim odmítnete přístup, který mohou snadno získat: udělá to špinavě, budou se chovat jako psanci, nebudou moci žádat o pomoc, Budu muset pokrýt všechny nehody.

10
dan

Dáte jim místní administrátorská práva na jejich pracovní stanici a na všechno ostatní, co chtějí. Vývojové prostředí je vždy izolováno od hlavní sítě. Je na IT, aby se ujistili, že jim poskytnete to, co nastavení kdy potřebují, a zároveň zajistí, aby nic v prostředí dev nemohlo poškodit hlavní síť. Naplánujte si dopředu a spolupracujte se správou na nákupu vybavení/softwaru, které k tomu potřebujete.

8
wrb

Několik věcí, které nebyly zmíněny v předchozích odpovědích a komentářích, které by byly argumentem pro vývojáře pracující s nejmenšími privilegiemi:

  1. V závislosti na odvětví, ve kterém pracujete, mohou existovat zákonné nebo regulační důvody, které zamezují zaměstnancům mít na svých pracovních stanicích zvýšená oprávnění. Povolení administrativního přístupu k vývojářům by mohlo organizaci vystavit riziku nedodržování předpisů.

  2. Pokud jsou komponenty vyvíjeny se zvýšenými oprávněními, může dojít k selhání během nasazení do jiných prostředí, která tato oprávnění nemají. Vývojáři mohou neúmyslně upgradovat nebo přidat knihovny do svých místních počítačů, které neexistují v jiných prostředích, a součásti mohou záviset na konkrétních verzích těchto knihoven. Také uživatelské účty, pod nimiž budou komponenty spuštěny v jiných prostředích, nemusí mít požadovanou databázi nebo jiný přístup, který předpokládal vývojář pracující se zvýšenými oprávněními. Viděl jsem, že se to stalo mnohokrát v minulosti. Někdy je zřejmé, proč nasazení selhalo, jindy ne, a musíte všechno vrátit zpět, dokud na to nepřijdete.

  3. Pokud vývojáři instalují nástroje nebo knihovny s otevřeným zdrojovým kódem a používají je pro vývoj, může dojít k neúmyslným licenčním omezením způsobu, jakým je nakonec software, který vyrábějí, distribuován, zejména pokud jsou podmínky licence „copyleft“ součástí licence. S použitím nástrojů nebo knihoven s otevřeným zdrojovým kódem není nic špatného, ​​prostě by to mělo být záměrné. Nechcete, aby se při dodání zjistilo, že nyní musíte uvolnit veškerý zdrojový kód zpět do komunity, protože vývojáři použili komponentu s otevřeným zdrojovým kódem, která měla v licenci přísné podmínky copyleft, které ve skutečnosti nečetli dříve, než začnou nainstaloval.

Něco, co jsem viděl udělat, je, aby vývojáři pracovali s nejmenšími oprávněními, ale umožnili jim požadovat zvýšená oprávnění na určité časové období. Poté tato žádost o „požární volání“ pro zvýšená oprávnění, která byla zaznamenána a sledována, je automaticky obnovena na konci požadovaného času.

8
Todd Dill

Na pár otázek je třeba odpovědět.

  1. Jaké aplikace musí tito vývojáři denně používat, vyžadují administrátorské privilages a existuje nějaký způsob, jak tyto aplikace nastavit tak, aby tomu tak nebylo?
  2. Jakým důvodům tito vývojáři potřebují administrátorské privilages, aby mohli dělat triviální každodenní úkoly a existuje způsob, jak tomu zabránit?
  3. Jsou tyto vývojové stroje připojeny k internetu?

Otázka by neměla být, jaká jsou rizika, otázkou by měla být (na kterou můžete pouze odpovědět), jaké jsou důvody, proč vývojáři potřebují mít administrátorský účet. Můžete jim založit účet „výkonného uživatele“ a dát jim možnost dělat přesně to, co potřebují, ale také omezit jejich schopnost poškozovat vaši síť.

Pokud jsou tyto stroje připojeny k internetu .... pak představíte velké riziko kvůli jejich schopnosti běžet cokoli a instalovat cokoli na tyto stroje. Tito vývojáři jsou dobře vývojáři, nejsou to odborníci na bezpečnost, je to jen otázka, kdy udělá chybu, která vystavuje síť malwaru.

Podívejte se například na Google. Zaměstnanec Google klikne na odkaz obsažený v okně MSN Messenger, stáhne malware, který využil výhody, které již společnost Microsoft opravila, a infikovalo celou síť.

Chtěl bych přidat zaměstnance Google kliknutím na odkaz nemá nic společného s touto otázkou, to bylo poukázat na to, že lidé udělají chybu, takže omezte vystavovatel.

4
Ramhound

Bezpečnostní rizika spojená s poskytováním možnosti vývojářům instalovat jejich počítače jsou četná. Zde je důvod, proč bych protestoval (mluvení jako sys admin)

1) Potenciální porušení nejlepších bezpečnostních postupů - Jedním z 8 bezpečnostních pravidel je pravidlo nejméně privilegovaných - zaměstnancům poskytujeme přístup pouze k tomu, co potřebují k plnění svých úkolů. Pokud mi někdo řekl, že jejich dev potřeboval administrátorský přístup k instalaci softwaru, aby mohl vykonávat svou práci, odpověděl bych „Proč pro ně jeden z mých zaměstnanců nemůže nainstalovat software pro ně?“. Centralizovaný bod pro instalaci softwaru zajišťuje, že oddělení IT přesně ví, jaký software je na jakém počítači.

2) Právní důvody - Možná, že jeden z vašich dev má méně než obdivuhodnou etiku a rozhodl se nainstalovat pirátský software. Nejen, že tento software je pravděpodobně protkán malwarem, ale pak můžete otevřít červy pro soudní spory, pokud byste měli být chyceni pirátským softwarem na vašem počítači. Za tyto počítače je považováno IT oddělení, které je za tyto počítače odpovědné, a jako takové je odpovědné za jejich audit a zajištění toho, že licence je v souladu s TOS každého kusu softwaru. I když je to pro vývojáře výhodné v tom, že mohou instalovat svůj vlastní software a neobtěžovat oddělení IT, pro IT oddělení vytvoříte mnohem více práce.

3) Neúmyslná instalace Malwar - zmíněno dříve, ale mohlo by to být dost nevinné. Zvýšení uživatelských oprávnění, aby mohli instalovat malware, je nechá reagovat na malware tím, že otevře infikovaný PDF, který dostali prostřednictvím e-mailu nebo jednotky stažením. Omezení přístupu uživatelů, takže nemohou instalační software pomůže zmírnit hrozbu malwaru.

4) Škodlivá aktivita - Podobně jako v bodě 2, ale co říká, že jeden z vašich zařízení nebude instalovat zadní dveře nebo záměrně neotevře další bezpečnostní hrozbu ve vaší síti. Byli byste překvapeni, kolik IT profesionálů to dělá, aby se pomstili, kdyby byli ukončeni, nebo by je jejich šéf srazil.

Celkově vzato bych musel proti tomu radit. I když lidé mohou argumentovat, že by to ušetřilo čas tím, že by jim zabránili v neustálém bugování IT při instalaci softwaru, ale já bych namítl, že „to zabere méně času, než to opraví bezpečnostní díry vytvořené tím, že uživatelům umožní nainstalovat svůj vlastní software“. . Pokud je to považováno za nutné IS=), měly by být skutečně umístěny do sítě, která nemá přímý přístup k vnějšímu světu.

4
DKNUCKLES

Řešením je instalace virtuálního počítače, který není připojen k doméně. Bude to docela hádka, ale je to lepší než být úplně ochromen politikami.

2
Louis Somers