Jak Transglot jest zabezpieczony.
ograniczone zakresem.
Jak Transglot jest zabezpieczony.
Szyfrowanie, kontrola dostępu, izolacja tenantów i ścieżka audytu – każdy element wymienia mechanizm, który go zapewnia. Rzeczy, których jeszcze nie zbudowaliśmy, są tutaj wymienione jako luki.
- tls 1.2 lub nowszy w transmisji
- webhooki podpisane hmac
- wpisy audytu tylko do dopisywania
- cztery role, pięć uprawnień tokenów
Szyfrowanie, dostęp, izolacja i audyt.
Szyfrowane przed opuszczeniem hosta
Kopie zapasowe bazy danych są szyfrowane podczas eksportu. Repozytorium kopii plików jest zabezpieczone hasłem i nie działa bez klucza. Dane uwierzytelniające aplikacji połączonych oraz sekrety webhooków są przechowywane w zaszyfrowanych kolumnach. Tokeny wdrażania są przechowywane jako hash SHA-256 i wyświetlane tylko raz, podczas tworzenia. Dyski produkcyjne nie są szyfrowane na poziomie woluminu, ponieważ nie zaimplementowaliśmy tej funkcji, a informacje na ten temat znajdziesz tutaj, a nie w procesie due diligence.
Podpisane podczas eksportu
Wychodzące webhooki są podpisywane za pomocą HMAC-SHA256 na podstawie znacznika czasu i treści. Znacznik czasu jest również wysyłany, dzięki czemu możesz wymusić własne okno ochrony przed powtórzeniem żądań.
Tożsamość i dostęp
Cztery role w przestrzeni roboczej dostępne w każdym planie, w tym darmowym: administrator, programista, recenzent i tłumacz, plus właściciele kont i członkowie działu rozliczeń. Dodatkowe uprawnienia per projekt i per język pozwalają nadać freelancerowi dostęp do jednego języka, bez widoczności innych danych. Logowanie SAML 2.0 z automatycznym provisioninguem (JIT) oraz provisioning SCIM 2.0 są dostępne w planie Enterprise, a logowanie hasłem można wyłączyć dla całej przestrzeni roboczej.
Izolacja tenantów
Każde zapytanie jest ograniczone do Twojej organizacji i projektu. Identyfikator należący do kogoś innego zwraca błąd 404 zamiast 403, dzięki czemu istnienie innej przestrzeni roboczej nigdy nie zostaje ujawnione. Wspólna pula pamięci dla dokładnych dopasowań jest jedynym celowym wyjątkiem, a każdy projekt może ją opuścić za pomocą przełącznika.
Ścieżka audytu
Zmiany ról, tworzenie tokenów, zmiany w rozliczeniach, konfiguracja SSO oraz logowania przez SSO są rejestrowane, a wpisów nie można edytować ani usuwać: model blokuje obie te operacje. Logowania hasłem nie są obecnie uwzględniane w ścieżce audytu. Właściciele i administratorzy w planie Enterprise mogą eksportować całą ścieżkę jako plik CSV. Nie ma tu łańcucha hashy ani podpisu kryptograficznego, więc nic nie wskazuje na ochronę przed manipulacją.
Dostępność i kredyty
Nie publikujemy tutaj procentowej wartości dostępności, ponieważ każda taka liczba byłaby jedynie naszą deklaracją. Plany Business i Enterprise obejmują kontraktowy miesięczny cel dostępności z harmonogramem kredytów serwisowych, który stanowi SLA.
Gdzie faktycznie stoi zgodność
Te same cztery wiersze, które czytają strona zaufania i centrum zaufania, pochodzące z tej samej konfiguracji. Pieczęć może powiedzieć „posiadana” tylko wtedy, gdy wartość logiczna tak wskazuje, a obecnie żadna z nich tego nie robi.
- SOC 2 Type II: audyt w toku
- ISO/IEC 42001 (AI management): w trakcie pozyskiwania
- GDPR: zgodne, ale nie certyfikowane
- CCPA / CPRA: zgodne, ale nie certyfikowane
O co pyta recenzent, odpowiadamy najpierw.
Pytania, które pojawiają się na początku przeglądu bezpieczeństwa, oraz odpowiedzi na nie, w kolejności, w jakiej zwykle napływają. Każdy wiersz odnosi się do konkretnej kontrolki w kodzie, a nie do ogólnych twierdzeń. Ostatni wiersz oznacza lukę i pozostanie tutaj, dopóki nie przestanie być aktualny.
- brak cytowanych ustaleń, ponieważ nie ma jeszcze raportu od strony trzeciej
- brak implikacji certyfikacji: tabela zgodności na stronie /trust odczytuje dane z konfiguracji
- badania prowadzone w dobrej wierze nigdy nie spotykają się z reakcją prawników
FAQ
Lista, która zwykle towarzyszy przeglądowi bezpieczeństwa.