Vartotojo vardas ir slaptažodis atsako tik į dalį prieigos klausimo. Įmonei taip pat gali reikėti žinoti, ar vartotojas atliko MFA, ar įrenginys yra valdomas ir ar užklausa pateikta iš tikėtinos vietos.

„Microsoft Entra Conditional Access“ šiuos signalus įtraukia į politikos sprendimą. Kai Odoo naudoja Microsoft Entra kaip tapatybės teikėją, „Conditional Access“ gali įvertinti „Microsoft“ prisijungimą prieš vartotojui grįžtant į Odoo.

Tai gali padaryti Odoo autentifikavimą nuoseklesnį su Microsoft valdoma aplinka. Tačiau netinkamai įdiegus, galima užblokuoti ir teisėtus vartotojus. Tikslas yra subalansuota politika, atitinkanti Odoo auditoriją ir duomenis.

Ką iš tikrųjų daro „Conditional Access“

„Microsoft“ apibūdina „Conditional Access“ kaip savo „Zero Trust“ politikos variklį. Politika veikia pagal „jei-tada“ principą: kai įvykdomos nustatytos sąlygos, Entra taiko sukonfigūruotą prieigos sprendimą. Oficialioje „Conditional Access“ apžvalgoje pateikiami dažni signalai, įskaitant vartotojus ir grupes, IP vietą, įrenginius, programas ir realaus laiko arba apskaičiuotą riziką.

Leidimo valdikliai gali reikalauti:

  • Daugiafaktorio autentifikavimo.
  • Nustatyto autentifikavimo stiprumo.
  • Pažymėto kaip atitinkančio įrenginio.
  • „Microsoft Entra“ hibridiškai prijungto įrenginio.
  • Patvirtintos kliento programos arba programos apsaugos politikos.
  • Slaptažodžio keitimo arba naudojimo sąlygų priėmimo.

Politikos taip pat gali blokuoti prieigą. Toms pačioms prisijungimo operacijoms gali būti taikomos kelios politikos, o „Microsoft“ paaiškina, kad turi būti įvykdyti visi taikomi politikos reikalavimai. Žr. kaip vertinamos „Conditional Access“ politikos.

Praktiniai Odoo politikos modeliai

Reikalauti MFA privilegijuotiems Odoo vartotojams

Odoo administratoriai, finansų darbuotojai ir vartotojai, galintys eksportuoti jautrius įrašus, yra tinkami kandidatai stipresniam autentifikavimui. „Microsoft Entra MFA“ reikalauja dviejų ar daugiau patvirtinimo metodų iš skirtingų veiksnių kategorijų, kaip aprašyta „Microsoft“ MFA dokumentacijoje.

Nereikia manyti, kad kiekvienas MFA metodas suteikia tokią pačią apsaugą. „Microsoft“ savo autentifikavimo apžvalgoje rekomenduoja nuo sukčiavimo atsparias parinktis, tokias kaip prieigos raktai, FIDO2 saugos raktai, „Windows Hello for Business“ ir sertifikatais pagrįstas autentifikavimas.

Praktiškas žingsnių planas gali būti reikalauti MFA visiems darbuotojams, o vėliau privilegijuotoms grupėms taikyti nuo sukčiavimo atsparų autentifikavimo stiprumą. Tinkama seka priklauso nuo turimų įrenginių, pasirengimo registracijai ir pagalbos pajėgumų.

Reikalauti tinkamo įrenginio

„Conditional Access“ gali reikalauti atitinkančio arba hibridiškai prijungto įrenginio. Tai gali būti naudinga, kai Odoo suteikia prieigą prie finansinių, darbuotojų ar operacinių duomenų, kurių nereikėtų atsisiųsti iš nevaldomo galinio įrenginio.

Šį sprendimą išbandykite su realiais vartotojais. Rangovai, bendri darbo kompiuteriai ir mobilieji vartotojai gali netikti darbuotojų nešiojamųjų kompiuterių politikai. Įrenginio atitiktis taip pat priklauso nuo tinkamos Microsoft konfigūracijos ir licencijavimo.

Vietą naudokite kaip vieną signalą, o ne tapatybės įrodymą

„Conditional Access“ gali blokuoti arba leisti prieigą pagal nustatytas vietas ir IP diapazonus. Tai gali padėti sumažinti riziką, kai organizacija veikia ribotoje geografinėje teritorijoje arba turi žinomus įmonės išeinančio ryšio adresus.

Vieta nėra tapatybės įrodymas. Darbuotojai keliauja, mobiliojo ryšio ryšiai kinta, o užpuolikai gali naudoti infrastruktūrą leidžiamame regione. Derinkite tai su stipriu autentifikavimu ir įrenginių valdymu.

Taikykite rizika pagrįstą politiką, kai tai licencijuota

„Microsoft Entra ID Protection“ gali įtraukti vartotojo ir prisijungimo riziką į „Conditional Access“. „Microsoft“ teigia, kad rizika pagrįstam „Conditional Access“ reikia „Entra ID P2“. Tai gali padėti griežčiau reaguoti į rizikingą prisijungimą, tačiau ši funkcija nėra įtraukta į visas „Entra“ licencijas.

„Conditional Access“ vertina signalus, prieinamus išduodant žetoną. Jis netikrina kiekvieno veiksmo, kurį vartotojas vėliau atlieka Odoo sistemoje.

„Conditional Access“ ir Odoo sesijos riba

„Conditional Access“ veikia „Microsoft“ autentifikavimo ir žetonų išdavimo metu. Odoo patvirtinus rezultatą ir sukūrus savo sesiją, vis tiek svarbus Odoo sesijos elgesys.

Pavyzdžiui, pašalinus vartotoją iš tikslinės grupės, jau išduotas žetonas nėra automatiškai pakeičiamas. „Microsoft“ politikos dokumentacijoje nurodo, kad naujai pridėtas vaidmens arba grupės narys politikai paklūsta, kai išduodamas naujas žetonas. Panašiai ir integracija, kuri Odoo grupes sinchronizuoja prisijungimo metu, nebūtinai iš karto panaikina aktyvią Odoo sesiją.

Todėl jūsų sprendime turėtų būti numatyta:

  • Odoo sesijos trukmė ir atsijungimo elgsena.
  • Kaip greitai atnaujinami Odoo prieigos susiejimai.
  • Avarinio atšaukimo procedūros.
  • Microsoft paskyros išjungimo poveikis.
  • Ar tinkamas tik „Microsoft“ interaktyvus prisijungimas.
  • Kaip administratoriai atgauna prieigą paslaugos teikėjo sutrikimo atveju.

Suplanuokite diegimą prieš taikydami politiką

„Microsoft“ „Conditional Access“ diegimo vadove rekomenduojama planuoti, naudoti bandomąjį vartotoją, pranešti apie pakeitimus ir užtikrinti, kad vartotojai galėtų registruotis MFA prieš pradedant taikyti politiką.

Diegiant Odoo, praktiška seka yra tokia:

  1. Užregistruokite Odoo ryšį ir patikrinkite jo atgalinį iškvietimą, aptikimo informaciją bei pasirašymo raktus.
  2. Išbandykite Microsoft prisijungimą su ne administratoriaus paskyra.
  3. Patvirtinkite Odoo paskyros sutapimą ir prieigos grupės rezultatus.
  4. Taikykite numatytą Sąlyginės prieigos politiką nedidelei bandomajai grupei.
  5. Peržiūrėkite prisijungimo žurnalus ir pagalbos atsiliepimus.
  6. Palaipsniui plėskite auditoriją.
  7. Įjunkite tik Microsoft pagrįstą interaktyvų prisijungimą tik tada, kai avarinė prieiga yra dokumentuota ir išbandyta.

Venkite plačių išimčių. Naudokite mažiausią būtiną išimtį, nurodykite jos savininką ir nustatykite peržiūros datą.

Supraskite licencijavimo ribą

Sąlyginė prieiga reikalauja Microsoft Entra ID P1. Microsoft 365 Business Premium taip pat apima Sąlyginės prieigos galimybes. Rizika pagrįstai Sąlyginei prieigai reikia Entra ID P2. Kiti valdikliai gali priklausyti nuo atskirų produktų, įskaitant Microsoft Intune arba Defender for Cloud Apps. Naujausia informacija pateikiama Sąlyginės prieigos licencijos reikalavimuose.

Organizacijos, neturinčios P1 ar P2, gali naudoti Microsoft saugumo numatytuosius parametrus kaip pagrindinį saugumo pagrindą, tačiau Microsoft pataria nenaudoti saugumo numatytųjų parametrų ir Sąlyginės prieigos kartu. Negrįskite Odoo prieigos plano funkcija, kol nepatvirtinta licencija ir nuomotojo konfigūracija.

Susiekite politiką su Odoo autorizacija

Sąlyginė prieiga nustato, ar Microsoft užbaigs prisijungimą. Odoo grupės nustato, kas vyksta vartotojui įėjus į Odoo. Kruopštus šių sluoksnių susiejimas gali sukurti aiškesnį modelį: Entra valdo autentifikavimo sąlygas, o patvirtintos grupės arba programos rolės susiejamos su konkrečia Odoo prieiga.

Skaitykite centralizuotą Odoo prieigos valdymą naudojant Microsoft Entra grupes ir programos roles apie autorizacijos pusę. Jei vis dar svarstote, ar SSO verta, pradėkite nuo kodėl turėtumėte apsaugoti savo Odoo instanciją su Microsoft SSO.

Taikykite Microsoft prisijungimo valdiklius Odoo 19

Mūsų Microsoft Entra SSO for Odoo modulis suteikia valdomą Odoo 19 jungtį su Microsoft Entra ID arba External ID. Jis patikrina Microsoft aptikimo informaciją ir pasirašymo raktus, palaiko interaktyvų prisijungimo testą ir, kai ryšys patvirtintas, gali reikalauti Microsoft prisijungimo interaktyviems vartotojams.

Modulis įgalina ryšį. Jis automatiškai nesukuria tinkamos Sąlyginės prieigos politikos ir nepanaikina būtinybės testuoti Odoo seansus bei teises. Peržiūrėkite modulį, jei norite kontroliuojamo integracijos taško, per kurį jūsų esamos Entra politikos gali valdyti Odoo prisijungimą.