După cum este cunoscut pentru aproape toți utilizatorii PowerShell, din motive de securitate, a fost introdusă o politică pentru a rula scripturi. Care are 4 moduri:
- Restricționat - este interzisă executarea oricărui script, este posibil să lucrați numai în consola interactivă
- AllSigned - toate scripturile trebuie semnate criptografic
- RemoteSigned - trebuie să fie semnat numai de la surse necreditate (de exemplu, Internet)
- Fără restricții - nivelul cel mai puțin sigur, toate scripturile pot fi executate
În versiunea V2 (pentru prezentul CTP3), scripturile PowerShell au fost asimilate fișierelor executabile și aceste fișiere au fost monitorizate neîntrerupt de politica privind politicile de restricționare a software-ului. Am scris deja despre acest lucru mai devreme: PowerShell V2 și Politicile de Restricționare a Software-ului. La început am fost foarte stresat, dar apoi am ajuns la opinia că a avut dreptate. Este greșit doar să nu vedem acest lucru (extensia ps1 nu apare nicăieri). Există două metode de combatere a acestei situații: specificați în mod explicit calea din care pot fi lansate fișierele .ps1 sau toate pot fi semnate.
Dacă există mai multe calculatoare în rețea, soluția cea mai potrivită pentru această sarcină va fi existența unui domeniu Active Directory și, dacă este posibil, a unui Enterprise Authity Certification (CA). Având un domeniu va rezolva o mulțime de sarcini, cum ar fi distribuirea unei politici SRP în cadrul unui domeniu, distribuirea unui certificat în domeniu, monitorizarea versiunii certificatului la care sunt semnate scripturile.
Deci, mai întâi trebuie să obținem un certificat, care va fi scris cu scripturi. Din motive de securitate, creați un cont de utilizator limitat de la care administratorul (în majoritatea cazurilor) va semna scenarii. În PowerShell In Action, sunteți încurajați să utilizați makecert.exe pentru a genera certificatul. care face parte din Visual Studio SDK, dar mi se pare mai potrivit să folosiți CA. În Windows Server CA pentru aceste scopuri există deja un șablon gata, numit Signing Code. Dar principala diferență nu este ce instrument veți genera certificatul și voi descrie procesul de obținere a unui certificat utilizând un CA domeniu.
După aceea, trebuie să vă conectați la acest utilizator, să executați Managerul de certificate (Start -> Run ... -> certmgr.msc) și să executați cererea de certificat. În lista de șabloane trebuie să existe o semnătură cu codul pe care am adăugat-o. Când se solicită certificatul, nu este necesar să închideți modulul snap-in certificat. Apoi, trebuie să exportăm partea deschisă a certificatului în fișierul x509 (cu extensia .cer). Va trebui să exportăm partea deschisă pentru a verifica semnătura și a organiza încrederea semnăturii în domeniu. Certificatul exportat trebuie trimis acum administratorului sau responsabililor pentru politica de grup.
În politicile de grup (cel mai adesea în politica de domeniu), trebuie să creați o nouă politică privind politicile de restricționare a software-ului și să adăugați regula de certificate în Regulile Additiona și să specificați certificatul exportat. Este necesar ca PowerShell să verifice căutările privind încrederea în certificatele pentru acesta în containerul Trusted Publishers și numai Politicile de restricționare a software-ului vă permit să distribuiți centralizat certificatele acestui container.
Acum puteți începe semnarea scripturilor. În acest scop, utilizați cmdletul Set-AuthenticodeSignature și sintaxa sa este:
Unde fișierul $ este calea către script și $ cert este obiectul certificatului, obținut după cum urmează:
aici indicăm în mod explicit că avem nevoie de un certificat care să aibă codul de codificare în EKU (Enchanced Key Usage). În cazul nostru, va fi doar 1. Dar dacă există mai multe dintre ele, atunci vom alege primul. Iată cum va arăta în practică:
Am demonstrat în mod clar cum funcționează acest lucru. Am tradus prima dată politica de execuție a scriptului în AllSigned și ne-am asigurat că scriptul nesemnat nu este executat. După aceea, am semnat acest scenariu și am încercat din nou. După cum puteți vedea, scriptul este executat acum.
Dacă condiția pentru distribuirea certificatului prin politica SRP nu este îndeplinită în containerul Trusted Publishers. atunci veți primi acest mesaj:
Așa rezolvăm sarcina de a executa numai un set verificat de scripturi. În acest sens, PowerShell 1.0 este mai puțin sigur și mai convenabil, deoarece nu putem bloca executarea fișierelor PS1 de către politica SRP ca o clasă și avem doar o ieșire - semnarea forțată a scripturilor. În versiunea V2, politica de execuție a scriptului este convenabil integrată cu SRP. Convenabilitatea integrării este că, pe lângă distribuirea certificatului în cadrul domeniului, SRP permite, de asemenea, ca aceste script-uri să fie executate prin depășirea limitării generale a fișierelor PS1 bazate pe această regulă.
În următorul post vă voi spune cum să simplificați procesul de semnare a scripturilor. Deci nu opriți :-)
Articole similare
Trimiteți-le prietenilor: