Inscrierea acordului de intreprindere si chiriasii Azure Active Directory – Cloud Adoption Framework

• 15.06.2020
• 3 minute de citit

In acest articol

Planul de inscriere a intreprinderii

Inscrierea la un acord de intreprindere (EA) reprezinta relatia comerciala dintre Microsoft si modul in care organizatia dvs. foloseste Azure. Acesta ofera baza pentru facturarea tuturor abonamentelor dvs. si afecteaza administrarea proprietatii dvs. digitale. Inscrierea dvs. in EA este gestionata prin portalul Azure EA. O inscriere reprezinta deseori ierarhia unei organizatii, care include departamente, conturi si abonamente. Aceasta ierarhie reprezinta grupurile de inregistrare a costurilor in cadrul unei organizatii.

Figura 1: O ierarhie de inscriere Azure EA.

• Departamentele ajuta la segmentarea costurilor in grupari logice si la stabilirea unui buget sau a unei cote la nivel de departament. Cota nu este aplicata ferm si este utilizata in scopuri de raportare.
• Conturile sunt unitati organizationale in portalul Azure EA. Acestea pot fi utilizate pentru a gestiona abonamentele si a accesa rapoartele.
• Abonamentele sunt cea mai mica unitate din portalul Azure EA. Sunt containere pentru serviciile Azure administrate de administratorul serviciului. Acestia sunt locul in care organizatia dvs. implementeaza serviciile Azure.
• Rolurile de inscriere EA leaga utilizatorii de rolul lor functional. Aceste roluri sunt:
  • Administrator Enterprise
  • Administrator departament
  • Proprietarul contului
  • Administrator de servicii
  • Contact de notificare

Consideratii de proiectare:

• Inscrierea ofera o structura organizatorica ierarhica pentru a reglementa gestionarea abonamentelor.
• Mai multe medii pot fi separate la nivel de cont EA pentru a sprijini izolarea holistica.
• Pot exista mai multi administratori numiti la o singura inscriere.
• Fiecare abonament trebuie sa aiba un proprietar de cont asociat.
• Fiecare proprietar de cont va deveni proprietar de abonament pentru orice abonamente furnizate in contul respectiv.
• Un abonament poate apartine unui singur cont la un moment dat.
• Un abonament poate fi suspendat pe baza unui set specificat de criterii.

Recomandari de proiectare:

• Folositi tipul de autentificare Cont de serviciu sau de scoala numai pentru toate tipurile de cont. Evitati sa utilizati tipul de cont Microsoft account (MSA).
• Configurati adresa de e-mail de contact pentru notificari pentru a va asigura ca notificarile sunt trimise catre o cutie postala de grup adecvata.
• Alocati un buget pentru fiecare cont si stabiliti o alerta asociata bugetului.
• O organizatie poate avea o varietate de structuri, cum ar fi structura functionala, divizionara, geografica, matriciala sau a echipei. Utilizati structura organizationala pentru a mapa structura organizatiei dvs. cu ierarhia de inscriere.
• Creati un departament nou pentru IT daca domeniile de afaceri au capacitati IT independente.
• Limitati si reduceti numarul de proprietari de conturi in cadrul inscrierii pentru a evita proliferarea accesului administratorului la abonamente si la resursele Azure asociate.
• Daca sunt utilizati mai multi chiriasi Azure Active Directory (Azure AD), verificati daca Proprietarul contului este asociat cu acelasi chirias ca si unde sunt furnizate abonamente pentru cont.
• Configurati Enterprise Dev / Test si medii de productie la un nivel de cont EA pentru a sprijini izolarea holistica.
• Nu ignora e-mailurile de notificare trimise la adresa de e-mail a contului de notificare. Microsoft trimite comunicatii importante la nivel de EA catre acest cont.
• Nu mutati sau redenumiti un cont EA in Azure AD.
• Verificati periodic portalul EA pentru a examina cine are acces si pentru a evita utilizarea unui cont Microsoft acolo unde este posibil.

Un chirias Azure AD asigura gestionarea identitatii si a accesului, care este o parte importanta a posturii dvs. de securitate. Un chirias Azure AD se asigura ca utilizatorii autentificati si autorizati au acces doar la resursele pentru care au permisiuni de acces. Azure AD furnizeaza aceste servicii aplicatiilor si serviciilor implementate in Azure si, de asemenea, serviciilor si aplicatiilor desfasurate in afara Azure (cum ar fi furnizorii cloud locali sau terti).

Azure AD este, de asemenea, utilizat de software ca aplicatii de serviciu, cum ar fi Microsoft 365 si Azure Marketplace. Organizatiile care utilizeaza deja Active Directory local isi pot utiliza infrastructura existenta si pot extinde autentificarea in cloud prin integrarea cu Azure AD. Fiecare director Azure AD are unul sau mai multe domenii. Un director poate avea multe abonamente asociate, dar un singur chirias Azure AD.

Puneti intrebari de securitate de baza in timpul fazei de proiectare Azure AD, cum ar fi modul in care organizatia dvs. gestioneaza acreditarile si modul in care controleaza accesul uman, aplicatia si programatic.

Consideratii de proiectare:

• Mai multi chiriasi Azure AD pot functiona in aceeasi inscriere.

Recomandari de proiectare:

• Utilizati conectarea simpla Azure AD fara sudura pe baza topologiei de planificare selectate.
• Daca organizatia dvs. nu are o infrastructura de identitate, incepeti prin implementarea unei implementari de identitate numai Azure-AD. O astfel de implementare cu Azure AD Domain Services si Microsoft Enterprise Mobility + Security ofera protectie end-to-end pentru aplicatiile SaaS, aplicatiile de intreprindere si dispozitivele.
• Autentificarea cu mai multi factori ofera un alt strat de securitate si o a doua bariera de autentificare. Aplica politici de autentificare cu factori multipli si acces conditionat pentru toate conturile privilegiate pentru o mai mare securitate.
• Planificati si implementati accesul de urgenta sau conturile de spargere pentru a preveni blocarea contului la nivel de locatar.
• Utilizati Azure AD Privileged Identity Management pentru gestionarea identitatii si a accesului.
• Daca dev / test si productia vor fi medii izolate dintr-o perspectiva identitara, separati-le la nivel de chiriasi prin mai multi chiriasi.
• Evitati sa creati un nou chirias Azure AD, cu exceptia cazului in care exista o justificare puternica a identitatii si a gestionarii accesului, iar procesele sunt deja in vigoare.