Szervezetek

Az OpenFactory organization API a organization tagságokat, valamint opcionális groups, units és teams elemeket tárolja. Célokat is ad a conversations/variants megosztásához.

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

Ez a hierarchia engedélyezési bemenet. Egy szerepkör-címke nem bizonyítja, hogy minden build, VM, download vagy deployment végpont érvényesíti a kívánt házirendet. Lásd a Szerepkörök és engedélyek hatóköre oldalt az egyes szerepkörök által jelenleg szabályozott útvonalakhoz.

Alapobjektumok

• Organization: legfelső szintű tagsági és adminisztrációs határ. Egy felhasználó több organizations tagja lehet.
• Group: organization tagok elnevezett gyűjteménye share célként; nem adminisztratív hierarchia.
• Unit: osztályszerű tároló saját tagsággal és tárolt workflow szerepkörökkel.
• Team: unit gyermeke saját tagsággal és tárolt workflow szerepkörökkel.

A felhasználóknak organization tagoknak kell lenniük, mielőtt alább adnád hozzá őket.

Biztonságos beállítási sorrend

1. Hozd létre az organization-t; a létrehozó owner lesz.
2. Adj hozzá egy második felelős ownert, mielőtt tartós műveletekhez az organization-ra támaszkodnál.
3. Hívd meg a felhasználókat a pontos e-mail címükre, és add meg a szükséges legalacsonyabb organization szerepkört.
4. Csak akkor adj hozzá units vagy teams elemeket, ha hatókörük valódi workflow-t változtat.
5. Tesztelj egy engedélyezett és egy megtagadott műveletet minden reprezentatív szerepkörrel.
6. Ellenőrizd a share és tagság viselkedését szerepkör eltávolítása és munkamenet-frissítés után.

A meghívók lejárnak, és olyan fióknak kell elfogadnia őket, amelynek e-mail címe egyezik a meghívóval. Ne továbbíts invite tokeneket ticketekben vagy nyilvános logokban.

Kontextus és tulajdon

Az organization kiválasztása befolyásolhatja a látható együttműködési adatokat, de az egyes resources továbbra is owner és share szabályokat hordoznak. Ne következtesd le a hozzáférést privát build vagy artifact felé csak azért, mert két felhasználó ugyanahhoz az organization-hoz tartozik. Használj explicit megosztást, ahol támogatott, és a download/VM műveletet külön teszteld.

Izolációs bizonyíték

Az organization és sharing útvonalak membership checks és same-organization validation műveleteket végeznek a hatókörükben lévő műveletekre. A „Tenant isolation” tágabb rendszertulajdonság, és cross-tenant denied-path tests kellenek conversations, builds, artifacts, VMs, API-k, cache-ek, exports és logs területén. Ne használd önmagában az organization hierarchiát ennek a bizonyítéknak.

Adminisztrációs védelmi intézkedések

• Több owner támogatott; az egyetlen owner nem távozhat.
• Csak owner emelhet fel másik ownert vagy törölheti az organization-t.
• A törlés és tagság eltávolítása befolyásolhatja a függő hozzáférést. Előbb készíts leltárt a shares, units, teams, aktív munkamenetek és owned resources elemekről.
• Őrizz meg külső auditnaplót, ha a házirended megköveteli; a jelenlegi szerepkörlista nem történeti audit trail.

Folytasd a Megosztás és Egységek és csapatok oldalakkal.