Puncte:3

Există un motiv real să folosiți conturile de administrator local „Run as” în loc să vă conectați ca administrator local?

drapel uz

Să începem prin a stabili scena -- sunt un administrator de sisteme junior însărcinat cu efectuarea unei tranziții a companiei către un model „cel puțin privilegiu”.Aceasta include eliminarea drepturilor de administrator de la utilizatorii noștri, care lucrează în principal cu Windows 10.

Acum, în acest moment, utilizatorii folosesc (în cea mai mare parte) conturi cu drepturi de administrator local. Acest lucru este evident destul de rău și lucrăm la schimbarea asta. Ideea propusă de n+1 al meu, în urma unui audit de securitate pe care l-au avut anul trecut, este să aibă două tipuri de utilizatori:

  • Primul tip va pierde privilegiile de administrator și, în cazul în care va avea nevoie de ele, va primi o parolă temporară pentru un cont cu drepturi de administrator pe computerul lor (care va expira după un timp, folosind LAPS)
  • Al doilea tip (și cel mai relevant pentru problema mea) este format din dezvoltatori -- unii pe tehnologii web, dar alții pe unele limbi de nivel foarte scăzut și care au nevoie să interacționeze cu registrele în mod semi-regulat, printre altele.
    Acești băieți vor avea un cont obișnuit, fără privilegii, și un cont de administrator (sau un cont „Run ca”) pe care îl vor folosi atunci când vor avea nevoie să ruleze lucruri ca administrator local. Aceasta înseamnă introducerea unui nume de autentificare și a unei parole de fiecare dată când apare UAC pentru a confirma utilizarea privilegiului de administrator. Acest cont „Run ca” nu va putea deschide o sesiune obișnuită, din motive evidente.

Problema vine cu acești dezvoltatori de școală veche. Mă tem că acest lucru se va transforma într-o problemă de politică de birou, deoarece pierderea drepturilor de administrator ar putea veni cu o mică pierdere de productivitate (mai ales pentru cei care folosesc privilegiile mai des) și, mai important, cu o oarecare frustrare.

Pot să înțeleg de unde vin. După ce am lucrat pentru aceeași companie ca un dezvoltator, înțeleg că a fi administrator local este confortabil. Cu toate acestea, sunt, de asemenea, familiarizat cu problemele de securitate și știu că a fi administrator pe o stație de lucru este un mare nu-nu.

Recent, a trebuit să prezint acestui al doilea tip de utilizator planurile noastre pentru viitor.Inutil să spun că dezvoltatorul principal al grupului „vechea școală” nu a fost mulțumit de asta și a pus o întrebare destul de bună (deși poate venind dintr-un punct de vedere apropiat al situației) la care nu am reușit. pentru a veni cu un răspuns satisfăcător.

Dacă scopul de a nu fi administrator local este acela de a evita răspândirea malware-ului sau capacitățile unui intrus de a exploata vulnerabilități, există o diferență reală între un utilizator care rulează programe care necesită privilegii ca acest cont de administrator „Run as” și doar execută este direct cu un cont de administrator în cazul unui fișier infectat?
Dezvoltatorul principal a susținut că o astfel de politică nu ar fi altceva decât o pierdere a timpului lor, deoarece ar duce la exact aceleași vulnerabilități de securitate ca doar a fi un administrator local în primul rând.

Este corect? Sunt conștient de afirmațiile că „92% dintre vulnerabilitățile Microsoft critice dezvăluite în 2013 pot fi atenuate prin eliminarea drepturilor de administrator”(SANS, 2016, citând un studiu Avecto) și alte astfel de afirmații și chiar simt că a fi administrator local nu este într-adevăr o idee bună, dar este soluția noastră cu adevărat mai bună?

Intenționăm să facem un test drive al noii soluții în viitorul apropiat, pentru a evalua potențiala pierdere a productivității și a determina dacă trebuie sau nu să găsim o altă soluție și mă tem că dezvoltatorul principal și alții care sunt enervați prin idee își va supraevalua intenționat eșecurile.

drapel in
IMO, această întrebare este mai potrivită pentru [security.se]
Puncte:5
drapel cv

Problema vine cu acești dezvoltatori de școală veche. Mi-e teamă că asta va fi transformat într-o problemă de politică de birou, de la pierderea administratorului drepturile ar putea veni cu o mică pierdere de productivitate (în special pentru cei care folosesc privilegiile mai des) și, mai important, unele frustrare.

Aceasta nu este lupta ta pe care trebuie să o duci, așa că nu o lupta. Dacă oamenii nu sunt mulțumiți de schimbare, spuneți-le să vorbească cu conducerea.

Este modificarea propusă mai sigură? Da. Riscul mai există în noul model? Da. Există mai puțin risc cu noul model? Da.

Deoparte, mi-ar plăcea să fiu persoana care a anulat acest lucru și apoi să găsesc datele companiei și proprietatea intelectuală ransomware. Și raiul ferește că ajunge la sistemele client prin software-ul tău. Întrebați dezvoltatorii dacă doresc această responsabilitate și responsabilitate.

spectras avatar
drapel ro
Aceste politici sunt de fapt o pierdere de timp, având în vedere numărul de timp de care aveți nevoie de permisiuni de administrator într-o zi obișnuită în care faceți dezvoltare software (cu excepția web, probabil). Și ei ratează complet ideea: ceea ce trebuie protejat pe un sistem de dezvoltator nu este sistemul, ci codul... care este perfect scris ca utilizator obișnuit. â cu alte cuvinte, nu face nimic pentru a proteja sistemele client, dar hei, cel puțin stația de lucru a dezvoltatorului nostru este puțin mai bine protejată, asta a meritat scăderea productivității.
Puncte:0
drapel ng

Depinde de spectrul tău de risc.

Ca prevenire a unui atac țintit, măsura este aproape inutilă.

Ca prevenire a unui atac din interior, măsura este, de asemenea, inutilă.

Pentru a împiedica dezvoltatorii să instaleze software piratat și să nu îl dezinstaleze înainte de un audit neașteptat - îmi pare rău.

Ca o prevenire a unui malware off-the-mill care infectează computerele departamentelor de vânzări și contabilitate - ei bine, funcționează, într-o măsură - și oricum acestea nu ar trebui să aibă nevoie de acces de administrator.

Pentru a preveni o neglijență gravă a administratorului de sistem - ei bine, oarecum, pentru că aceștia își dezvoltă obiceiul de a scrie parola rapid și fără a citi cu adevărat ce se cere.

În afară de asta, obținerea de mașini de dezvoltare unde rezidă cel mai mult IP sau infrastructura de rezervă unde se află totul pentru a se alătura AD este proastă în primul rând.

Creează un singur punct de eșec. Schimbarea cu politicile îi face pe dezvoltatori supărați și inventivi în a ocoli teatrul de securitate.

p.s. Încă nu am văzut o implementare AD care nu este creată la nivel de administrator de domeniu în 5 ani, indiferent dacă administratorii legitimi o știu sau nu.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.