← Wybierz perspektywę, która pasuje do Twojego zespołu

Dla przedsiębiorstw IT

Skracacz, którego zespół ds. bezpieczeństwa nie odrzuci.

Mierzysz zgodność, czas reakcji na incydenty i liczbę ankiet dostawców, które możesz przetrwać. Elido to skracacz, którego Twój zespół bezpieczeństwa nie odrzuci.

Kontakt ze sprzedażą Przeczytaj raport zaufania

SAML SSO + SCIM przez naszego dostawcę SSO lub natywnie - Okta, Entra ID, Google
Główna baza w UE; wyboru regionu dla przestrzeni roboczej jeszcze nie ma
SOC 2 w przygotowaniu, raport nie został wydany
ISO 27001 niecertyfikowane; DPA dostępny na życzenie

Where data is hosted

EU-hosted primary data

Default + EU residency

Redirect edge nodes (no per-workspace region choice)

SAML + OIDC

Protokół SSO

WorkOS

Dostawca SSO/SCIM

730 dni

Domyślne przechowywanie dziennika audytu (konfigurowalne)

SOC 2

W przygotowaniu, raport nie został wydany

Jak działa SSO

Okta lub Entra ID → SAML → Elido. Dwanaście minut od startu.

SSO jest routowane przez WorkOS, który normalizuje różnice protokołów między SAML 2.0 a OIDC oraz specyficzne dla każdego dostawcy tożsamości niuanse, których nikt nie chce samodzielnie utrzymywać. Twój zespół konfiguruje aplikację SAML raz w swoim dostawcy tożsamości; Elido mapuje użytkowników po domenie e-mail → połączeniu.

Step 1
User signs in
okta.com / login.microsoftonline.com
IdP authenticates against the corporate directory.
Step 2
SAML assertion
WorkOS connection · domain-routed
Email-domain → IdP connection mapping, no per-user setup.
Step 3
Elido session
edge auth · 200 OK
Session token issued, scope derived from group claims.
Step 4
Workspace landing
app.elido.app/w/your-org
Role + IP allowlist evaluated; audit row written.

Prowizja SCIM

Dodaj użytkownika w Okta. Jest w Elido w ciągu pięciu minut.

Synchronizacja katalogów SCIM 2.0 automatycznie prowizjonuje i deprowizjonuje użytkowników. Mapowanie grup z dostawcy tożsamości konwertuje grupy na role obszaru roboczego Elido, więc awans w systemie HR przenosi się do Elido bez zgłoszenia serwisowego. Odchodzący pracownicy są deprowizjonowani w cyklu synchronizacji SCIM, z unieważnionymi aktywnymi sesjami i zalogowanym działaniem.

Automatyczna prowizja przy dodaniu do grupy
Przynależność do grupy dostawcy tożsamości → zaproszenie do obszaru roboczego, bez ręcznego kroku
Mapowanie ról z grup
engineering-eu → edytor, finance → przeglądający, konfigurowalne
Deprowizja = unieważnienie sesji
Zdarzenie DELETE unieważnia tokeny; klucze API unieważniane przez politykę
Każde zdarzenie SCIM jest audytowane
Log tylko do dołączania z aktorem, stanem przed/po, źródłowym IP

Szczegółowe omówienie SCIM i SSO →

SCIM directory sync

workspace · acme-eu

Live · WorkOS

1
User added in Okta
Joins the elido-eu-engineering directory group as part of HR onboarding.
okta.comPOST /scim/v2/Users
T+75s
2
WorkOS pushes to Elido
SCIM sync cycle picks up the create event; no manual invite needed.
workos.com → elido.appscim.create user@org
T+150s
3
Elido provisions the user
Account created, workspace invitation surfaced in pending state.
api-coreuser.id = usr_01HK…
T+225s
4
Group claim → role
engineering → editor; billing-admins → admin. Mapping is configurable.
policyrole: editor (workspace.eu)
T+300s
Deprovision is the same flow in reverse - DELETE event revokes sessions and rotates affected API keys per policy.

Model autoryzacji

RBAC oparty na Cedar, nie sztywna hierarchia trójpoziomowa.

Poniższa macierz to widok domyślny. Niestandardowe role pozwalają wyrazić rzeczy takie jak 'tworzenie linków tylko w tej domenie' lub 'tylko do odczytu w analityce, bez dostępu do płatności' jako polityki Cedar. Role są ograniczone per obszar roboczy, więc różne jednostki biznesowe mogą stosować różne struktury ról.

Built-in role permissions

Cedar policies · custom roles override

Permission	Owner	Admin	Member	Read-only	API key
Create / edit links
Manage custom domains
View analytics
Manage billing
Invite & manage members
Rotate API keys

Allowed

Scoped - set via Cedar policy

Denied

Policy eval at request time, not at loginaudit · every change

Zobacz model bezpieczeństwa →Przewodnik po niestandardowych rolach → dokumentacja

Co faktycznie dostaje przedsiębiorstwo IT

SAML SSO + SCIM przez naszego dostawcę SSO lub natywnie - Okta, Entra ID, Google
Główna baza w UE; wyboru regionu dla przestrzeni roboczej jeszcze nie ma
SOC 2 w przygotowaniu, raport nie został wydany
ISO 27001 niecertyfikowane; DPA dostępny na życzenie
BAA w Business+ dla obciążeń sąsiadujących z HIPAA
Dedykowane POP krawędziowe dostępne w kontraktach Enterprise

Czego działy IT w korporacjach naprawdę potrzebują od skracacza

Skracacze typu Shadow-IT nie przechodzą weryfikacji działów zakupów w trzech kwestiach: kto ma dostęp, gdzie są dane i czy możemy to audytować. Poniższe funkcje wypełniają te luki.

Tożsamość i provisioning

SAML SSO via WorkOS z automatycznym provisioningiem użytkowników SCIM

SSO odbywa się za pośrednictwem WorkOS, który wspiera SAML 2.0 i OIDC dla każdego głównego IdP: Okta, Azure AD / Entra ID, Google Workspace, OneLogin, Ping i innych. Mapowanie domena e-mail → połączenie oznacza, że użytkownicy są kierowani do właściwego IdP bez żadnej konfiguracji po ich stronie. Synchronizacja katalogu SCIM automatycznie dodaje i usuwa użytkowników: nowi pracownicy dodani do odpowiedniej grupy IdP otrzymują zaproszenie do obszaru roboczego Elido w ciągu kilku minut; odchodzący pracownicy są usuwani w cyklu synchronizacji SCIM bez konieczności ręcznego zgłoszenia. Grupy z IdP mapują się na role w Elido; konfigurujesz mapowanie raz, a zmiany ról w IdP propagują się automatycznie. Jest to integracja zarządzana przez WorkOS - nie utrzymujemy oddzielnych konektorów dla każdego IdP; WorkOS normalizuje protokoły, a Elido korzysta z jednego punktu końcowego SCIM.

Model autoryzacji

Niestandardowe role z RBAC w stylu Cedar - więcej niż właściciel/administrator/członek

Model ról Elido opiera się na Cedar, co oznacza, że uprawnienia są wyrażeniami polityki ocenianymi w czasie rzeczywistym, a nie stałą trójpoziomową hierarchią. Standardowo otrzymujesz role: Owner, Admin, Member i Viewer. Niestandardowe role pozwalają definiować polityki typu 'może tworzyć linki w tej domenie, ale nie może usuwać ani zmieniać reguł routingu' lub 'dostęp tylko do odczytu analityki, ale bez dostępu do ustawień rozliczeń'. Role są przypisywane per obszar roboczy, a nie globalnie - korporacja z wieloma obszarami może mieć różne struktury ról dla każdej jednostki biznesowej. Allowlista IP (zakresy CIDR) jest oceniana wraz ze sprawdzeniem ról: użytkownik z odpowiednią rolą, ale spoza dozwolonego zakresu IP, otrzyma odmowę dostępu. Jest to kluczowe dla zespołów hybrydowych, gdzie kontrahenci mają dostęp do innego podzbioru danych niż etatowi pracownicy.

Audyt i SIEM

Log audytowy typu append-only przesyłany do Twojego SIEM w czasie rzeczywistym

Każda akcja w workspace'ie - utworzenie, aktualizacja, usunięcie linku; zmiana ustawień; zaproszenie członka i zmiana roli; wydanie i rotacja klucza API; przejęcie domeny niestandardowej; eksport - trafia do dziennika audytu typu append-only z aktorem, znacznikiem czasu, źródłowym IP, różnicą przed/po i ustrukturyzowanym typem zdarzenia. Logi są domyślnie przechowywane 730 dni, z możliwością konfiguracji dla każdego workspace'a. Firehose SIEM przesyła zdarzenia w czasie rzeczywistym przez webhook (podpisany HMAC-SHA256) do Splunk, Datadog, ELK lub dowolnego odbiornika HTTP. Dziennik można przeglądać w panelu, ale nie edytować; jest append-only w aplikacji, a każdy wpis jest powiązany hashem z poprzednim, więc manipulację można wykryć. Postawa zgodności: dziennik audytu jest głównym dowodem w przeglądach kontroli dostępu, zarządzaniu zmianami i reagowaniu na incydenty. Zdarzenie meta „retention purge” jest zapisywane, gdy stare wpisy wygasają, więc sama luka też podlega audytowi.

Zarządzanie danymi (Data governance)

Rezydencja danych w EU, allowlista IP i eksport do BigQuery dla wymagań governance

Główna baza danych, magazyn analityczny i kopie zapasowe są hostowane w UE. Węzły przekierowań w USA (Ashburn) i Singapurze również przetwarzają żądania odwiedzających; wybór regionu dla pojedynczej przestrzeni roboczej nie jest jeszcze dostępny. Lista dozwolonych adresów IP (CIDR) w planie Business ogranicza dostęp do przestrzeni roboczej do znanych zakresów wyjściowych - przydatne dla zespołów na VPN lub ze stałymi adresami biurowymi. Eksport do BigQuery wysyła pełny strumień zdarzeń kliknięć i dziennika audytu do należącego do Ciebie zbioru danych BigQuery, według harmonogramu lub na wyzwalacz. Obsługiwane są też Snowflake i S3. Dla obciążeń regulowanych, które wymagają, by dane pozostały w konkretnej infrastrukturze, self-hosting jest dostępny na podstawie umowy (Enterprise); napisz na [email protected]. BAA HIPAA jest dostępny w planie Business+ - zabezpieczenia techniczne (szyfrowanie, ścieżka audytu, kontrola dostępu, powiadamianie o naruszeniach) są wdrożone; BAA to prawna otoczka wokół nich.

Due diligence dostawcy

Dowody zgodności: DPA, podprocesorzy, stan bezpieczeństwa

Na pytania działu zakupów odpowiadamy bez długiej korespondencji: DPA jest dostępny na życzenie pod adresem [email protected] (standardowe klauzule umowne UE w komplecie); lista podprocesorów jest publiczna na /legal/subprocessors (13 dostawców); zgłoszenia podatności trafiają na [email protected], a security.txt leży pod standardową ścieżką. Status certyfikacji bez ogródek: SOC 2 jest w przygotowaniu i nie wydano żadnego raportu; ISO 27001 nie jest certyfikowane. Aktualny stan śledzi Trust Center na /trust.

Stos, z którym będziesz pracować

SSO (SAML / OIDC)
Provisioning SCIM
Niestandardowe role (RBAC)
Lista dozwolonych adresów IP
Dziennik audytu + strumień SIEM
Rezydenacja danych w UE
HIPAA BAA

Co mierzy Twój zespół bezpieczeństwa

Liczba podprzetwarzających: 13, lista publiczna
Retencja dziennika audytu: 730 dni domyślnie
Czas odpowiedzi DSAR: Poniżej 30 dni

Elido vs Bitly Enterprise vs Bl.ink dla korporacyjnego IT

Bitly Enterprise i Bl.ink to opcje klasy korporacyjnej z dużym stażem. Poniższe porównanie skupia się na funkcjach, które faktycznie oceniają zespoły IT, a nie na hasłach marketingowych.

Możliwość	Elido	Bitly Enterprise	Bl.ink
Protokół SSO	SAML 2.0 + OIDC via WorkOS	SAML 2.0 w planie Enterprise	SAML 2.0 w planie Enterprise
Provisioning SCIM	Business i wyższe, via WorkOS	Tylko plan Enterprise	Dostępny w Enterprise
Niestandardowe role (RBAC)	Wyrażenia polityki oparte na Cedar	Sztywne poziomy ról	Granularne, udokumentowane
Allowlista IP	CIDR, Business+	Tylko Enterprise	Dostępna
Log audytowy → SIEM	Strumień webhook w czasie rzeczywistym	Codzienny eksport; opcja Enterprise RT	Oparty na API; ręczna konfiguracja SIEM
Retencja logów audytowych	730 dni domyślnie, konfigurowalne	Standardowo 1 rok	Konfigurowalna w Enterprise
Rezydencja danych w EU	Domyślna dla wszystkich planów	Opcjonalna w Enterprise	Dostępna; nie jest domyślna
Eksport do BigQuery	Zaplanowany, Business+	Brak dokumentacji	Oparty na API; brak natywnego eksportu

Pytania korporacyjnego IT

Które IdP wspiera SSO?

Każde IdP wspierające SAML 2.0 lub OIDC - Okta, Azure AD / Entra ID, Google Workspace, OneLogin, Ping, Rippling i inne. Integracja odbywa się przez WorkOS, który normalizuje różnice w protokołach. Jeśli Twoje IdP obsługuje SAML lub OIDC, będzie działać. Konfiguracja to proces prowadzony przez WorkOS: konfigurujesz aplikację SAML w swoim IdP, wklejasz URL metadanych do Elido i gotowe.

Jak działa deprovisioning SCIM?

WorkOS obsługuje punkt końcowy SCIP 2.0. Gdy użytkownik zostaje usunięty z odpowiedniej grupy w Twoim IdP, WorkOS wysyła zdarzenie DELETE do Elido. Elido natychmiast unieważnia tokeny sesji użytkownika i oznacza konto jako nieaktywne. Aktywne klucze API powiązane z tym użytkownikiem nie są automatycznie unieważniane - jest to osobny krok konfigurowany w ustawieniach SCIM, domyślnie ustawiony na 'unieważnij przy deprovisioningu'. Akcja usunięcia pojawia się w logu audytowym w cyklu synchronizacji SCIM (zazwyczaj poniżej 5 minut).

Co obejmuje allowlista IP?

Logowanie do panelu, żądania API i potwierdzenia dostarczenia webhooków. Obsługiwana jest notacja CIDR; wiele zakresów oddziela się przecinkami. Żądania spoza allowlisty zwracają kod 403 z zarejestrowanym zdarzeniem audytowym - nie ma cichych odrzuceń. Allowlista IP jest oceniana po uwierzytelnieniu, a nie przed, więc nieudana próba autoryzacji spoza listy i tak jest logowana.

Czy możemy otrzymać BAA dla zgodności z HIPAA?

Tak, w planie Business+. BAA obejmuje rolę Elido jako partnera biznesowego (business associate) dla obszarów roboczych, w których dane PHI mogą przechodzić przez metadane linków lub analitykę. Techniczne zabezpieczenia (szyfrowanie w spoczynku i w transmisji, ścieżka audytu, kontrole dostępu, powiadamianie o naruszeniach) są już wdrożone. Skontaktuj się z [email protected] w celu uzyskania szablonu BAA.

Jaki jest status SOC 2?

SOC 2 jest w przygotowaniu i nie wydano żadnego raportu. ISO 27001 nie jest certyfikowane. Nie udostępniamy dowodów audytu, których nie mamy; napisz na [email protected], aby otrzymać aktualne odpowiedzi do kwestionariusza bezpieczeństwa. Aktualny stan śledzi Trust Center na /trust.

Jak działają niestandardowe role - czy mogę ograniczyć zespół do trybu tylko do odczytu w konkretnej domenie?

Tak. Niestandardowe role definiują polityki oparte na Cedar, które mogą ograniczać uprawnienia do konkretnych domen, folderów lub operacji (tworzenie/odczyt/aktualizacja/usuwanie). Rola pozwalająca na tworzenie linków tylko w określonej domenie niestandardowej i dostęp tylko do odczytu do analityki jest prawidłową polityką. Role są przypisane do obszaru roboczego; użytkownik może mieć różne role w różnych obszarach. Ocena polityki następuje w momencie żądania, a nie podczas logowania.

Czy dla klientów Business dostępna jest dedykowana opcja edge?

Plan Business korzysta z współdzielonych punktów obecności (POP) edge Elido (region UE, USA Wschód, Azja-Pacyfik). Dedykowany edge - własna flota węzłów przekierowujących, odizolowana od ruchu innych najemców - to temat na rozmowę o planie Enterprise. Skontaktuj się z [email protected]. Self-hosting jest również dostępny na podstawie umowy (Enterprise).

Jakie jest SLA dla powiadamiania o naruszeniach?

24 godziny na powiadomienie klienta o potwierdzonych naruszeniach danych osobowych; 72 godziny na powiadomienie organu nadzorczego (RODO Art. 33 / GDPR Art. 33). Powiadomienie obejmuje to, co wiemy w danym momencie - nie czekamy na pełną analizę śledczą. Proces opisany jest na /trust/incident-response.