Как Transglot е защитен.
ограничени.
Как Transglot е защитен.
Шифроване, контрол на достъпа, изолация на наематели и аудиторски след, като всяко от тях назовава механизма, който го осигурява. Нещата, които още не сме изградили, са описани тук като пропуски.
- tls 1.2 или по-нова версия при предаване
- hmac-подписани уебхукове
- аудиторски редове само за добавяне
- четири роли, пет възможности за токени
Шифроване, достъп, изолация и аудит.
Шифровано, преди да напусне хоста
Резервните копия на базата данни са шифровани при изнасяне. Хранилището за файлови резервни копия е защитено с парола и отказва да работи без ключа си. Идентификационните данни на свързаните приложения и секретите на уебхуковете се съхраняват като шифровани колони. Токените за внедряване се съхраняват като SHA-256 хеш и се показват веднъж, при създаването. Живите дискове не са шифровани на ниво том, защото не сме изградили това и трябва да научите за това тук, а не по време на проверка.
Подписано при изнасяне
Изходящите уебхукове са подписани с HMAC-SHA256 върху времевия печат и тялото. Времевият печат също се изпраща, за да можете да приложите свой собствен прозорец за повторение.
Идентичност и достъп
Четири работни роли във всеки план, включително безплатния: администратор, разработчик, рецензент и преводач, плюс собственици на акаунти и членове за фактуриране. Разрешенията за всеки проект и за всеки език са допълнителни, така че на фрийлансър може да се даде достъп само до един език, без да вижда нищо друго. Вход чрез SAML 2.0 с JIT предоставяне и SCIM 2.0 provisioning са налични в Enterprise плана, а входът с парола може да бъде изключен за цялото работно пространство.
Изолация на тенанта
Всяка заявка е ограничена до вашата организация и проект. Идентификатор, принадлежащ на друг потребител, връща грешка 404 вместо 403, така че съществуването на друго работно пространство никога не се разкрива. Споделеният пул за памет с точно съвпадение е единственото умишлено изключение и всеки проект може да го деактивира чрез превключвател.
Аудиторският дневник
Промените в ролите, създаването на токени, промените във фактурирането, конфигурацията на SSO и входовете чрез SSO се записват, а редовете не могат да бъдат редактирани или изтривани: моделът предизвиква грешка и при двете операции. Влизанията с парола все още не са част от дневника. Собствениците и администраторите в Enterprise плана могат да експортират целия дневник като CSV. Няма хаш верига и няма криптографски подпис, така че нищо тук не гарантира защита срещу манипулации.
Наличност и кредити
Тук не публикуваме процент, защото всяка посочена цифра би била просто наша дума за собствената ни наличност. Плановете Business и Enterprise включват договорна месечна цел за наличност с график за сервисни кредити и този график представлява SLA.
Къде всъщност стои съответствието
Същите четири реда, които страницата за доверие и центърът за доверие четат, от една и съща конфигурация. Печатът може да каже „притежаван“ само когато булева стойност го потвърди, а днес никоя от тях не го прави.
- SOC 2 Type II: одитът е в ход
- ISO/IEC 42001 (AI management): в процес на получаване
- GDPR: съответства, но не е сертифицирано
- CCPA / CPRA: съответства, но не е сертифицирано
Какво пита рецензентът, отговорено първо.
Въпросите, с които започва една проверка за сигурност, и отговорите, в реда, в който обикновено пристигат. Всеки ред представлява контрол в кодовата база, а не твърдение за нея. Последният ред е пропуск и той остава тук, докато престане да бъде верен.
- няма цитирани констатации, защото все още няма доклад от трета страна
- без подразбираща се сертификация: таблицата за съответствие в /trust се чете от конфигурацията
- проучванията с добри намерения никога не срещат адвокати
ЧЗВ
Списъкът, който обикновено пристига с одит за сигурност.