Organizacijos

OpenFactory organization API saugo organizacijų narystes ir neprivalomas groups, units bei teams. Jis taip pat teikia tikslus conversations/variants bendrinimui.

organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
    ├── unit members
    └── teams
        └── team members

Ši hierarchija yra įvestis autorizacijai. Rolės etiketė neįrodo, kad kiekvienas build, VM, download ar deployment endpoint taikytų numatytą policy. Žr. Vaidmenys ir teisės, kad sužinotumėte, kokius maršrutus kiekviena rolė šiuo metu valdo.

Pagrindiniai objektai

• Organization: aukščiausio lygio narystės ir administravimo riba. Vartotojas gali priklausyti kelioms organizations.
• Group: pavadintas organization narių rinkinys, naudojamas kaip share tikslas; tai ne administracinė hierarchija.
• Unit: skyriui panašus konteineris su savo naryste ir saugomomis workflow rolėmis.
• Team: unit vaikinis elementas su savo naryste ir saugomomis workflow rolėmis.

Vartotojai turi būti organization nariai, prieš juos pridedant žemiau struktūroje.

Saugios sąrankos eilė

1. Sukurkite organization; kūrėjas tampa owner.
2. Pridėkite antrą atskaitingą owner, prieš patikėdami organization ilgalaikėms operacijoms.
3. Kvieskite vartotojus tiksliais el. pašto adresais ir priskirkite žemiausią reikiamą organization rolę.
4. Pridėkite units ar teams tik tada, kai jų apimtis keičia tikrą workflow.
5. Patikrinkite vieną leistiną ir vieną atmestą veiksmą su kiekviena reprezentacine role.
6. Peržiūrėkite share ir narystės elgseną po rolės pašalinimo ir sesijos atnaujinimo.

Kvietimai nustoja galioti ir turi būti priimti paskyros, kurios el. paštas atitinka kvietimą. Nesiųskite invite tokenų užklausose ar viešuose žurnaluose.

Kontekstas ir nuosavybė

Organization pasirinkimas gali paveikti matomus bendradarbiavimo duomenis, tačiau atskiri resources vis dar turi owner ir share taisykles. Neiškaskite prieigos prie privataus build ar artifact tik todėl, kad du vartotojai priklauso tai pačiai organization. Naudokite aiškų bendrinimą, kur palaikoma, ir atskirai patikrinkite download/VM veiksmą.

Izoliacijos įrodymas

Organization ir sharing maršrutai atlieka membership checks ir same-organization validation savo apibrėžtoms operacijoms. „Tenant isolation“ yra platesnė sistemos savybė ir reikalauja cross-tenant denied-path testų conversations, builds, artifacts, VMs, API, cache, exports ir logs srityse. Nenaudokite vienos organization hierarchijos kaip to įrodymo.

Administravimo apsaugos

• Palaikoma keli owners; vienintelis owner negali išeiti.
• Tik owner gali paaukštinti kitą owner arba ištrinti organization.
• Ištrynimas ir narystės pašalinimas gali paveikti priklausomą prieigą. Pirmiausia inventorizuokite shares, units, teams, aktyvias sesijas ir owned resources.
• Saugokite išorinį audit įrašą, jei to reikalauja jūsų policy; dabartinis rolių sąrašas nėra istorinis audit trail.

Tęskite su Bendrinimas ir Padaliniai ir komandos.