Защо данните за офиса ви се нуждаят от изолирана база данни

Когато ИТ или екип по сигурността оценява инструмент за резервации на работното място, въпросникът обикновено пита за криптиране, еднократно влизане и къде се намират сървърите. Рядко задава въпроса, който е най-важен за тази категория данни: физически ли са отделени данните на нашата организация от тези на всеки друг клиент, или са колона в споделена таблица?

Резервацията на бюра изглежда като данни с нисък риск, докато не изброите какво съдържа: кой е бил в коя сграда в кой ден, на кое бюро, до кого, с кои посетители и къде е паркирал колата си. Това е дневник на движението на вашия персонал. Той заслужава същата изолация, която бихте изисквали за HR данни или данни за заплати.

Тази статия обяснява двата начина, по които SaaS доставчиците съхраняват данни на много наематели, защо Desk & Park дава на всяка организация собствена изолирана база данни и какво означава това решение за хората, които одобряват сигурността, поверителността и съответствието.

Две архитектури, един компромис

Почти всеки SaaS продукт е с много наематели (multi-tenant): едно приложение обслужва много клиенти. Въпросът е къде живее границата между клиентите.

Споделена база данни, колона за наемателя

Обичайният подход. Редовете на всеки клиент стоят в едни и същи таблици и всеки ред носи tenant_id. Всяка заявка трябва да филтрира по него. Приложението, а не базата данни, отговаря за това клиентите да са разделени.

Популярен е, защото е евтин за поддръжка: една база данни, една схема, една миграция. Той е и източникът на цял клас инциденти със сигурността. Един липсващ WHERE tenant_id = ? в една от хиляди заявки, един отчет, който свързва таблици без филтъра, един бъг в кеширането, и клиент А вижда данните на клиент Б. Тези бъгове не са хипотетични; те са повтаряща се категория разкрити SaaS пробиви, и са трудни за откриване, защото всяка отделна заявка изглежда коректна.

Изолирана база данни за всяка организация

Всеки клиент получава собствена база данни, със собствени таблици, собствени идентификационни данни и собствени резервни копия. Приложението се свързва с правилната база данни за организацията, която прави заявката. Няма филтър tenant_id, който да забравите, защото в базата данни няма друг наемател, от когото да изтекат данни.

Това струва на доставчика повече оперативна дисциплина: осигуряване, мигриране и наблюдение на стотици или хиляди бази данни вместо на една. Тази цена е смисълът. Тя се плаща от доставчика, веднъж, в инженерна работа, вместо от клиента, по-късно, в инцидент.

Как е изграден Desk & Park

Desk & Park работи с архитектура база данни за всяка организация. Конкретно:

Контролен слой (control plane) съдържа само това, което е нужно за маршрутизиране и таксуване: имена на организации, план, съответствието между организация и нейната база данни и собствената одитна следа на платформата. Не съдържа резервации, планове на етажи, нито директория на служителите.
Една PostgreSQL база данни за всяка организация съдържа всичко за тази организация: потребители, роли, локации, карти, бюра, паркоместа, зали, резервации, чекирания, посетители, известия и одитния дневник на организацията.
Идентификационни данни за всяка организация. Приложението отваря връзка към базата данни на организацията с идентификационни данни, ограничени до тази база данни. Заявка от организация А не може да бъде изпълнена срещу базата данни на организация Б дори по грешка, защото приложението никога не държи връзка към нея.
Резервни копия, възстановяване и изтриване за всяка организация. Резервните копия се правят за всяка база данни. Възстановяването на една организация до вчерашното ѝ състояние не засяга никой друг. Изтриването на организация в края на договора означава премахване на нейната база данни, което е проверимо, пълно изтриване, а не DELETE WHERE tenant_id, който се надява да е намерил всеки ред.

Кодът на приложението е споделен; данните не са. Това е границата, която одиторът може да посочи.

Какво купува изолацията на хората, които одобряват

За CISO: по-малък радиус на поражение

Уязвимост в слоя от заявки на система с много наематели излага всички клиенти наведнъж. С изолирани бази данни същият клас бъг не може да прекоси границата на организацията, защото границата се налага от機 двигателя на базата данни и идентификационните данни на връзката, а не от логиката на приложението. Изолацията не прави приложението имунизирано срещу бъгове; тя превръща бъг на едно място в проблем на един клиент, вместо в проблем за цялата платформа.

За DPO: ясни отговори на въпросите по GDPR

Прегледите за защита на данните задават предвидими въпроси, а базата данни за всяка организация им дава кратки отговори.

Въпрос	Отговор с изолирана база данни
Къде са нашите данни?	Във вашата база данни, в региона на платформата в ЕС, отделно от всички други клиенти.
Кой може да ги достъпва?	Приложението, с идентификационни данни, ограничени до вашата база данни, и дежурният персонал на оператора според документираната процедура за достъп.
Можете ли да докажете изтриване?	Да: вашата база данни се премахва и премахването се записва в одитната следа на платформата.
Можете ли да възстановите само нашите данни?	Да: резервните копия са за всяка организация.
Можете ли да експортирате всичко?	Да: експортът е дъмп на една база данни, а не филтриран извлек.

Правото на изтриване и задължението за ограничаване на обработката стават операции върху база данни с ясен обхват, а не функции на приложението, които трябва да се тестват за пълнота.

За ръководителя по съответствие: защитим контрол

Рамки като ISO 27001 и SOC 2 изискват от доставчика да демонстрира логическо разделение между клиентите. „Всяка заявка филтрира по наемател“ е контрол, който трябва да се проверява отново за всяка нова заявка. „Всеки клиент има собствена база данни и идентификационни данни“ е контрол, който се проверява веднъж, структурно, и се запазва с растежа на продукта. Вторият е много по-лесен за доказване, както за доставчика, така и за собствения одит на клиента.

За CIO: предвидима производителност и жизнен цикъл

Тежкият отчет на една организация не забавя сутрешния пик на чекирания на друга, защото те не споделят таблици или индекси. Миграциите се разгръщат за всяка база данни поотделно, така че проблем може да бъде уловен при една организация, преди да стигне до следващата. Прекратяването на договора е премахване на база данни, а не проект за почистване.

Останалата част от историята за сигурността

Изолацията е основата, а не цялата сграда. Контролите, които ИТ екипите очакват, стоят върху нея и си струва да бъдат изброени, защото добра архитектура със слаба автентикация все пак е слаба:

Еднократно влизане чрез OpenID Connect с вашия доставчик на идентичност и SCIM осигуряване, така че новите и напускащите служители се създават и деактивират от вашата директория, а не ръчно.
Двуфакторна автентикация (TOTP) и passkeys (WebAuthn), с политика на ниво организация за задължително MFA.
Политики за сигурност за всяка организация: изтичане на сесията, правила за пароли, списъци с разрешени IP адреси.
Управление на активните сесии, така че администраторът да може да вижда и прекратява сесии.
Одитен дневник за всяка организация, записващ кой какво е променил, в собствената база данни на организацията.
Плащания чрез Stripe, така че данните за картите изобщо не достигат до платформата.
Ролеви достъп: служителите виждат и резервират; администраторите конфигурират; членовете на борда и мениджърите получават отчети, ограничени до техните екипи.

Нито едно от тези неща не е необичайно в корпоративния SaaS. Необичайното е комбинирането им със слой от данни, при който границата между клиентите е физическа.

Въпроси, които да зададете на всеки доставчик за работното място

Ако сравнявате инструменти, тези пет въпроса отделят маркетинга от архитектурата:

Нашите данни в отделна база данни ли са, или в споделени таблици с колона за наемателя?
Резервните копия, възстановяванията и изтриванията извършват ли се за всеки клиент поотделно?
Какви идентификационни данни използва приложението, за да достигне до нашите данни, и ограничени ли са те до нас?
Как доказвате разделението между клиентите пред вашите одитори?
Може ли бъг в отчет или експорт някога да върне редове на друг клиент?

Доставчик с изолирана база данни отговаря на всичките пет с по едно изречение. Доставчик със споделена база данни трябва да опише процес на тестване.

Изолацията трябва да бъде по подразбиране

Данните за работното място са лични данни за физическото присъствие на вашите служители. Най-евтината архитектура за доставчика поставя тези данни до данните на всеки друг клиент и се доверява на приложението да ги държи разделени. Desk & Park избра по-скъпата, така че границата между организациите да е база данни, а не филтър.

Можете да прочетете техническите подробности в резюмето на архитектурата на страницата „Как работи“ и в политиката за поверителност на платформата. За корпоративно внедряване с еднократно влизане, SCIM и преглед на сигурността страницата с цените има контакт за Enterprise.