Organizācijas

OpenFactory organization API glabstī organizāciju dalību un neobligātās groups, units un teams. Tas arī nodrošina mērķus conversations/variants kopīgošanai.

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

Šī hierarhija ir ievade autorizācijai. Lomas etiķete nedod pierādījumu, ka katrs build, VM, download vai deployment endpoint piemēro paredzēto policy. Skatiet Lomas un atļaujas, lai uzzinātu, kurus maršrutus pašlaik kontrolē katra loma.

Pamatobjekti

• Organization: augstākā līmeņa dalības un administrācijas robeža. Lietotājs var piederēt vairākām organizations.
• Group: nosaukts organization dalībnieku kopums, ko izmanto kā share mērķi; tā nav administratīva hierarhija.
• Unit: nodaļai līdzīgs konteiners ar savu dalību un saglabātām workflow lomām.
• Team: unit pakārtots elements ar savu dalību un saglabātām workflow lomām.

Lietotājiem jābūt organization dalībniekiem, pirms viņus pievieno zemāk struktūrā.

Droša iestatīšanas secība

1. Izveidojiet organization; izveidotājs kļūst par owner.
2. Pievienojiet otro atbildīgo owner, pirms paļaujaties uz organization ilgtermiņa operācijām.
3. Uzaiciniet lietotājus uz precīziem e-pasta adresēm un piešķiriet zemāko nepieciešamo organization lomu.
4. Pievienojiet units vai teams tikai tad, ja to apjoms maina faktisku workflow.
5. Pārbaudiet vienu atļauto un vienu noraidītu darbību ar katru reprezentatīvo lomu.
6. Pārskatiet share un dalības uzvedību pēc lomas noņemšanas un sesijas atsvaidzināšanas.

Uzaicinājumi beidzas un tos jāpieņem kontam, kura e-pasts atbilst uzaicinājumam. Nesūtiet invite tokenus pieteikumos vai publiskos žurnālos.

Konteksts un īpašumtiesības

Organization izvēle var ietekmēt redzamos sadarbības datus, taču atsevišķiem resources joprojām ir owner un share noteikumi. Nenozīmējiet piekļuvi privātam build vai artifact tikai tāpēc, ka divi lietotāji pieder vienai organization. Izmantojiet skaidru kopīgošanu, kur tā atbalstīta, un atsevišķi pārbaudiet download/VM darbību.

Izolācijas pierādījums

Organization un sharing maršruti veic membership checks un same-organization validation savām ierobežotajām operācijām. „Tenant isolation“ ir plašāka sistēmas īpašība un prasa cross-tenant denied-path testus conversations, builds, artifacts, VMs, API, cache, exports un logs jomās. Neizmantojiet tikai organization hierarhiju kā šo pierādījumu.

Administrēšanas aizsardzība

• Atbalstīti vairāki owners; vienīgais owner nevar aiziet.
• Tikai owner var paaugstināt citu owner vai dzēst organization.
• Dzēšana un dalības noņemšana var ietekmēt atkarīgo piekļuvi. Vispirms inventarizējiet shares, units, teams, aktīvās sesijas un owned resources.
• Saglabājiet ārēju audit ierakstu, ja to prasa jūsu policy; pašreizējais lomu saraksts nav vēsturisks audit trail.

Turpiniet ar Kopīgošana un Vienības un komandas.