Securitate

Asistent AI pentru clasificarea și rezolvarea automată a ticketelor recurente cu Ollama si PowerShell

Echipele de suport IT primesc zilnic ticket-uri repetitive (resetare parolă, cont blocat, VPN nefuncțional, mapare drive etc.). Triajul manual și redactarea răspunsurilor consumă timp prețios.

Această soluție citește descrierile ticket-urilor dintr-un fișier CSV (exportat din helpdesk), le clasifică automat pe categorii folosind un model AI local (Ollama) și sugerează pașii de rezolvare pe baza unei baze de cunoștințe interne — totul fără ca datele clienților să părăsească rețeaua.

[mai mult...]

Stocarea cheilor de recuperare BitLocker în Active Directory

Baza de date Active Directory poate fi utilizată ca locație centrală pentru stocarea cheilor de recuperare BitLocker. Puteți configura Politica de grup (GPO) pentru a salva automat cheile de recuperare pentru computerele cu BitLocker activat în AD. Administratorii pot apoi recupera în siguranță cheile de recuperare pentru computere din AD și pot debloca unitățile de stocare criptate ale dispozitivelor în cazul în care un utilizator uită parola BitLocker.

Peisajul administrării BitLocker

În prezent, Active Directory nu mai este sistemul principal/recomandat pentru gestionarea cheilor de recuperare BitLocker. Astăzi, pentru administrarea BitLocker, aveți la dispoziție soluții mai bune bazate pe cloud:

Microsoft Endpoint Manager (Intune). Acesta este înlocuitorul principal al MBAM.
Microsoft BitLocker Administration and Monitoring (MBAM) este învechit.
În mediile conectate la Entra ID și în cele hibride, cheile de recuperare BitLocker sunt de obicei depozitate la Entra ID prin intermediul politicilor Intune/de înscriere a dispozitivelor.

Stocarea cheilor BitLocker bazată pe AD este utilizată acum, de obicei, pentru:

  • Mediile locale vechi
  • Dispozitivele hibride alăturate la domeniu
    Rețelele izolate/fără conexiune la internet

Pentru organizațiile care planifică noi implementări, recomandăm să acorde prioritate gestionării BitLocker bazate pe Intune și depozitării cheilor de recuperare în Entra ID în locul stocării de recuperare bazate pe AD DS vechi, ori de câte ori este posibil.

Reguli de decizie

Ar trebui să utilizați copiile de rezervă BitLocker din AD DS în următoarele cazuri:

  • mediu exclusiv Active Directory local
  • nu există o identitate în cloud (Entra ID)
  • rețeaua dvs. este restricționată/izolată

Ar trebui să utilizați Intune/Entra ID în următoarele cazuri:

  • există o identitate în cloud sau hibridă
  • dispozitivele sunt alăturate la Entra ID sau într-un mod hibrid
  • Microsoft Endpoint Manager este disponibil

Nota Bene: Rețineți că Entra ID/Intune este planul de control implicit pentru recuperarea BitLocker în mediile Microsoft moderne. AD DS este o soluție de rezervă mai veche, pe care ar trebui să o utilizați numai în cazul în care identitatea în cloud nu este disponibilă.

În cazul în care utilizați Intune/Entra ID, ar trebui să omiteți toate secțiunile referitoare la schema AD și GPO. În cazul în care utilizați AD DS, omiteți secțiunile referitoare la Intune/Entra.

Cerințe de mediu și validarea schemei Active Directory

Nota Bene: Înainte de a configura backup-ul BitLocker în AD, vă recomandăm să verificați dacă schema AD a fost extinsă corespunzător și dacă atributele legate de BitLocker sunt prezente la nivel de schemă.

Rețineți că metoda de stocare a cheii de recuperare BitLocker depinde de arhitectura mediului. Ar trebui să alegeți una dintre următoarele:

  • AD DS local (vechi/hibrid)
  • Microsoft Entra ID (nativ în cloud)
  • Politici BitLocker gestionate de Intune (aceasta este abordarea modernă recomandată)

Cerințe de sistem

  • Computere cu Windows 10 sau 11 care rulează edițiile Pro, Education sau Enterprise;
  • Schema Active Directory trebuie să conțină un set de atribute personalizate ale obiectelor de tip computer pentru stocarea cheilor de recuperare BitLocker (disponibile în AD începând cu Windows Server 2012).

Pentru a verifica versiunea schemei AD:

(Get-ADObject `
(Get-ADRootDSE).schemaNamingContext `
-Properties objectVersion).objectVersion

Această operațiune verifică versiunea schemei AD pentru a se asigura că extensiile schemei sunt aplicate la nivel de pădure. Rețineți că versiunea schemei are doar caracter informativ (trebuie să verificați compatibilitatea cu BitLocker folosind verificarea prezenței ldapDisplayName).

Pentru a verifica prezența extensiei de schemă BitLocker, executați următoarea comandă:

$schemaNC = (Get-ADRootDSE).schemaNamingContext
Get-ADObject $schemaNC -Property objectVersion, name
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
-Filter “ldapDisplayName -like ‘msFVE*'” `
-Properties ldapDisplayName |
Select-Object ldapDisplayName

Validarea compatibilității BitLocker cu Active Directory ar trebui să includă:

  • Verificarea versiunii schemelor
  • Confirmarea prezenței atributelor legate de BitLocker (msFVE*)
  • În cele din urmă, verificarea stării de funcționare cu ajutorul comenzii:

Get-ADReplicationFailure -Target * -Scope Forest
Get-ADReplicationPartnerMetadata -Target * | Select LastReplicationSuccess

Chiar și în cazul în care atributele de schemă sunt prezente, copierea de rezervă BitLocker poate eșua din următoarele motive:

  • lipsa aplicării GPO
  • lipsa permisiunilor de scriere pe computer
  • direcționarea incorectă către unitatea organizațională (OU)
  • dispozitivul hibrid nu este conectat corespunzător la AD DS

Pentru o implementare reușită a BitLocker, trebuie să îndepliniți toate condițiile următoare:

  • Există o parolă de recuperare
  • Starea protecției BitLocker este activată
  • Obiectul msFVE-RecoveryInformation există în AD
  • Parola de recuperare poate fi recuperată din ADUC/PowerShell

Atribute obligatorii ale schemei Active Directory

Trebuie să existe următoarele cinci atribute:

  • ms-FVE-KeyPackage
  • ms-FVE-RecoveryGuid
  • ms-FVE-RecoveryInformation
  • ms-FVE-RecoveryPassword
  • ms-FVE-VolumeGuid
[mai mult...]

Audit de Cod și Securitate Automatizat în CI/CD folosind Local AI

Echipele de dezvoltare necesită Code Review-uri rapide pe Pull/Merge Requests pentru a detecta vulnerabilități (ex. SQL Injections, OWASP, credențiale hardcodate) și bug-uri logice. Procesul manual este lent și blochează developerii seniori. Trimiterea codului sursă proprietar către soluții de AI din cloud (ex. OpenAI, GitHub Copilot) încalcă politicile interne de confidențialitate și Data Leakage. Este necesară o soluție locală (on-premise) care să auditeze automat codul modificat, fără costuri per apel.

[mai mult...]

Audit AI al configurațiilor GPO – identificare riscuri de securitate cu Ollama (Local AI) + PowerShell

Administratorii de sistem gestionează zeci sau sute de Group Policy Objects (GPO-uri) într-un domeniu Active Directory. Verificarea manuală a acestora pentru riscuri de securitate (parole slabe, drepturi excesive, setări periculoase) este consumatoare de timp și predispusă la erori umane.

Această soluție automatizează exportul configurațiilor GPO și le trimite unui model AI local (rulat prin Ollama) care analizează setările și returnează un raport cu riscuri identificate și recomandări — fără ca datele să părăsească rețeaua internă.

[mai mult...]

Open WebUI – cum îți faci propriul “ChatGPT” privat, accesibil de oriunde

Există o nevoie tot mai mare de utilizare a modelelor de limbaj (LLM) pentru asistență în programare, analiză de documente și generare de conținut, însă soluțiile comerciale (ex: ChatGPT, Claude) implică trimiterea datelor sensibile în cloud și costuri recurente de abonament.

Soluția propusă este implementarea Open WebUI, care transformă motorul Ollama într-o suită completă de productivitate, similară cu ChatGPT Plus/Enterprise. Aceasta aduce funcționalități critice care lipsesc din Ollama standard: RAG (Retrieval Augmented Generation) pentru analiza documentelor PDF/DOCX, acces la Căutare Web în timp real, generare de imagini, suport multi-user și o interfață grafică modernă, accesibilă din browser de la distanta prin (desktop/mobil/laptop) .

Functionalitati:

  • Chat cu propriile Documente (RAG):

    • Ollama CLI: Nu poate citi fișiere direct.

    • Open WebUI: Are un sistem integrat de vectorizare. Poți încărca PDF-uri, fișiere Excel sau Word direct în chat (folosind butonul + sau tastând #). Modelul va răspunde strict pe baza informațiilor din documentele tale.

  • Web Search Integration:

    • Ollama CLI: Modelele sunt limitate la data antrenării (knowledge cutoff).

    • Open WebUI: Se poate conecta la Google/DuckDuckGo. Dacă întrebi “Care este prețul acțiunilor Nvidia azi?”, AI-ul va căuta pe net și va sintetiza răspunsul actual.

  • Memorie și Istoric:

    • Salvează toate conversațiile pe titluri, le poți arhiva, șterge sau continua oricând (Ollama CLI pierde sesiunea la închidere).

  • Comparare Modele (Arena Mode):

    • Poți rula două modele simultan (ex: Llama 3 vs Mistral) în aceeași fereastră pentru a vedea care generează un cod sau un text mai bun.

  • Multi-User & Securitate:

    • Permite crearea de conturi pentru mai mulți utilizatori (colegi), cu roluri de Admin sau User, fiecare având propriul istoric privat de conversații.

Documentatie oficiala : https://docs.openwebui.com/

Interfata:

[mai mult...]

Cheile de acces Microsoft Entra de pe Windows acceptă acum autentificarea rezistentă la phishing

Cheile de acces pe Windows tocmai au beneficiat de o îmbunătățire semnificativă. Microsoft lansează suportul pentru cheile de acces Microsoft Entra pe Windows, permițând utilizatorilor să creeze chei de acces asociate dispozitivului, stocate în containerul Windows Hello, și să se autentifice folosind metodele Windows Hello, precum recunoașterea facială, amprenta digitală sau codul PIN.

Ceea ce face această actualizare deosebit de interesantă este domeniul de aplicare. Aceasta nu se limitează la dispozitivele conectate la Entra sau înregistrate. Utilizatorii de pe PC-uri Windows personale, partajate și neadministrate vor putea, de asemenea, să utilizeze cheile de acces pentru a se conecta la resursele protejate de Entra.

Ce sunt cheile de acces Microsoft Entra pe Windows

Recent, Microsoft a adăugat deja suport pentru cheile de acces sincronizate prin intermediul unor furnizori precum Apple iCloud Keychain sau Google Password Manager, pe lângă cheile de acces obișnuite, acceptate de mai mult timp, cum ar fi cheile de securitate FIDO2.

Această nouă funcție abordează problema dintr-o perspectivă diferită. În loc să se bazeze pe o cheie de securitate externă sau pe un furnizor terț de chei de acces, cheile de acces sunt acum stocate direct în containerul Windows Hello de pe dispozitiv. Autentificarea se realizează prin metodele Windows Hello pe care utilizatorul le-a configurat deja: recunoaștere facială, amprentă digitală sau cod PIN.

Aceste chei de acces sunt legate de dispozitiv și nu se sincronizează, astfel încât, dacă un utilizator se conectează de pe un alt PC cu Windows, va trebui să înregistreze o nouă cheie de acces și pe acel dispozitiv. Acesta este același model ca și în cazul unei chei de securitate hardware, dar integrat direct în Windows.

În ce fel diferă aceasta de Windows Hello for Business

Windows Hello for Business rămâne soluția recomandată pentru dispozitivele gestionate, înscrise în Entra sau înregistrate. Este perfect integrată cu gestionarea dispozitivelor și acceptă atât autentificarea pe dispozitiv, cât și autentificarea pentru resursele din cloud.

Cheile de acces Entra pe Windows sunt o completare a acesteia, nu un înlocuitor. Acestea sunt concepute special pentru scenarii în care Windows Hello for Business nu este utilizat, cum ar fi dispozitivele personale, PC-urile partajate sau mașinile neadministrate, unde utilizatorii au în continuare nevoie de acces rezistent la phishing la resursele protejate de Entra.

Un aspect de care trebuie să țineți cont: utilizatorii nu pot înregistra o cheie de acces pe Windows dacă există deja o acreditare Windows Hello for Business pentru același cont și container. Așadar, pe dispozitivele dvs. complet gestionate și conectate la Entra, Windows Hello for Business va continua să aibă prioritate.

Când va avea loc lansarea

Lansarea se desfășoară în două etape: versiune preliminară publică și disponibilitate generală:

  • Versiune preliminară publică: Mijlocul lunii Martie – sfârșitul lunii Aprilie 2026
  • Disponibilitate generală:   Mijlocul lunii Martie – mijlocul lunii Aprilie 2026 Mijlocul lunii Aprilie – mijlocul lunii Mai 2026

Nu există niciun impact asupra vreunei organizații, cu excepția cazului în care se face înscrierea. Așadar, dacă nu se doreste testarea acestei noi functii, nu trebuie facut nimic.

[mai mult...]