# Cum protejează platforma credențialele de integrare

Când conectați o sursă de acces cu o cheieAPIsau OAuth, autorizați platforma să apeleze furnizorul în numele dvs. Această pagină explică ce se întâmplă cu aceste credențiale, ce date colectează platforma și controalele existente pe **ZebraByteCloud**.

## Ce conectează

Access reviews support three connection methods:

- **OAuth.** Atunci când **Add Source** oferă **Connect** pentru un furnizor, aprobați platforma pe ecranul de consimțământ al furnizorului. platforma stochează jetoanele OAuth necesare pentru reîmprospătarea accesului, nu parola furnizorului. disponibilitatea OAuth depinde de furnizor și de configurația de implementare. - **APIcheie.** Creați un jetoan pe furnizor și lipiți-l în platformă în timpul **Add Source**. Utilizați jetoanele cu cele mai puține privilegii descrise de fiecare ghid de conector. - **CSV.** Nu se stochează credențiale live; încărcați o export pentru instrumentele la care platforma nu se poate conecta direct.

Pentru fluxurile de cheie OAuth șiAPI, platforma trebuie să dețină acreditări care pot fi utilizate din nou la fiecare sincronizare sau campanie.

## Data flow

Diagrama de secvență de mai jos urmează același ciclu de viață ca și pașii numerotate care urmează.Mesajele sunt citite de sus în jos în fiecare secțiune. **CSV** încărcări skip credențial de stocare; numai căile cheie OAuth șiAPIutilizează conectare, stocare și sincronizare.

## Credential lifecycle

1. Administratorii organizației (și rolurile cu permisiuni de conector echivalente) pot crea conectori; vizionarii pot vedea că un conector există, dar nu primesc niciodată valori secrete stocate. 2. **Encryption înainte de stocare.**APIchei, accesul non-secret și reîmprospătați jetoane, iar secretele clientului sunt serializate și criptate cu **AES-256-GCM** folosind o cheie de criptare de implementare.Fiecare linie de conector stochează rezultatul într-un blob de acreditare **encriptat.**APIchei, setările non-secrete (de exemplu, un ID de site Crisp) rămân în câmpuri de configurare separate. **Nu există nici un nou echo back.** Listing

Unele integrări utilizează un token gestionat prin implementare** (de exemplu, plugin-ul Crisp Marketplace).În acest model, platforma nu copiază tokenul plugin-ului partajat în conexiunea stocată a organizației dvs.; dovediți proprietatea asupra resurselor separat.

## Credential encryption

Credențialele de integrare primesc criptarea câmpului la nivel de aplicație utilizând AES-256-GCM și un nonce aleatoriu pentru fiecare blob de credențiale criptate.

Acest lucru corespunde garanțiilor descrise în [Politica de confidențialitate](https://www.zebrabyte.ro/privacy): criptare în tranzit, criptare în repaus și ** AES-256** la nivel de serie pentru câmpurile sensibile, acolo unde este cazul.

platforma nu este zero-cunoaștere: serviciul trebuie să proceseze credențiale pentru a rula integrări. Obiectivul de proiectare este de a minimiza expunerea** (fără afișarea din nou a secretelor, decriptare numai atunci când este necesar, control strict al accesului) și de a separa** cheia de criptare de datele criptate.

Pentru izolarea rețelei, criptarea în repaus a datelor, păstrarea cheilor și backup-uri, consultați [ZebraByteCloud Infrastructure Security](/docs/deployment/infrastructure-security).

## Access control and tenant isolation

- Conectorii aparțin organizației dumneavoastră. controalele de acces la baze de date și de autorizare sunt direcționate către chiriașul dumneavoastră. - ** Proprietarii și administratorii** pot crea, reconecta și șterge conectori. **Viewers** pot enumera conectori, dar nu pot gestiona acreditările. - Modificările reușite ale conectorilor fac obiectul aceluiași model organizațional **logging de audit** ca și alte acțiuni sensibile. standardele de inginerie tratează acreditările și jetoanele ca date care nu trebuie să apară în jurnal; raportați o preocupare la [security@the platform.com] (mailto:security@the platform.com) dacă credeți că a fost expus un secret.

## Ce colectează platforma de la furnizori

Pentru evaluările accesului, platforma colectează **metadatele de membru** pe care furnizorul le dezvăluie: nume, e-mail, rol, pavilion de admin, starea contului, starea MFA și ultima conectare, acolo unde este disponibilă.

**Datele de integrare** sunt utilizate numai pentru a opera caracteristicile pe care le activați.Nu le folosim pentru publicitate, revânzare, decizii de credit, profiluri de anunțuri sau pentru instruirea modelelor de inteligență artificială generalizate.

## Recomandări înainte de conectare

- Preferați **OAuth** atunci când **Add Source** oferă acest lucru pentru furnizor. - Creați un token dedicat, scalabil **APIpe furnizor (citiți-l numai acolo unde permite ghidul). Evitați cheile globale sau personale atunci când există un token scalabil. - Stocați tokenul într-un manager de parole până când îl lipiți o dată în platformă; nu-l împărtășiți în chat sau e-mail. - **Rotați sau revocați** la furnizor atunci când cineva pleacă sau integrarea este neutilizată, apoi ștergeți sursa din platformă sau reconectați cu un nou token. - Examinați cine are acces administrator ** în organizația platformei dvs.; acești utilizatori pot gestiona conectori.

Unele API-uri ale furnizorilor nu oferă o credențială doar pentru citire sau cu un domeniu de aplicare restrâns pentru listarea conturilor. Ghidurile lor de conectare exclud acest lucru în mod explicit. Când este necesară o credențială largă, utilizați un cont dedicat în cazul în care furnizorul permite acest lucru, rotiți credențialul pe un program și eliminați sursa atunci când revizuirea nu mai este necesară.

## Network Restrictions

Unii furnizori pot restricționa acreditărileAPIla anumite adrese IP sursă. Pentru **ZebraByteCloud**, lăsați această restricție dezactivată, cu excepția cazului în care platforma a furnizat adrese egress fixe pentru mediul dvs. Pentru o implementare **auto-gazdă**, puteți permitelista adreselor egress fixe configurate de operatorul de infrastructură.

O restricție IP care nu include adresa de ieșire a implementării determină eșecul testului de conectare sau al campaniei, chiar și atunci când credențialul în sine este valabil.

## Self-hosted deployments

When you run the platform yourself, **you** operate the encryption key, HTTPS ingress, database, object storage, backups, and access to production systems. Configure the required `encryption-key` in probod settings; it encrypts sensitive data at rest the same way as ZebraByte Cloud's application layer. See [Configuration file](/docs/deployment/configuration/config-file#encryption-key) and [Architecture & Migration Reference](/docs/deployment/self-hosting/docker-compose).

ID-urile și secretele aplicației Connector OAuth pentru fiecare furnizor sunt, de asemenea, configurații de implementare în setările auto-hostate, nu valori trecute de client în fiecare caz.

## Related documentation

- [Access Reviews overview](/docs/product/access-review/overview) - [Connector directory](/docs/product/access-review/directory) - [ZebraByteCloud Infrastructure Security](/docs/deployment/infrastructure-security) - [Politică de confidențialitate](https://www.zebrabyte.ro/privacy) - [Portal de conformitate](https://trust.zebrabyte.ro)