Възможности
Когато преместите програмата си за съответствие в SaaS платформа, вие предавате наистина чувствителен материал: регистъра си на рисковете, записите си за инциденти, договорите с ICT доставчиците си, одитните си доказателства, оценките си на пропуските. Това е вид данни, за които регулаторът пита и които конкурентът би искал да прочете. Затова един честен въпрос към всеки доставчик е съвсем прост: кой от вашата страна може да види моите данни и кога?
За повечето SaaS продукти честният отговор е „поддръжката и инженерингът могат, когато решат, че им е нужно". Venvera работи по обратния начин. По подразбиране нито един инженер на Venvera не може да отвори работното пространство на вашия тенант. Отварянето на вашия тенант през пътя „view as" на поддръжката се случва само когато някой от вашите собствени администратори на тенанта одобри конкретна, ограничена във времето заявка. Тази статия обяснява как работи този поток и защо изградихме продукта така, че изходната позиция да е затворена.
По подразбиране достъпът е затворен
Venvera е многотенантна. Данните на всеки тенант са изолирани на ниво база данни чрез row-level security, така че всяка заявка се изпълнява ограничена до една организация. Освен това отварянето на клиентски тенант през пътя „view as" на поддръжката е защитено с бариера: платформата отказва да стартира сесията, ако за този тенант не съществува активно, одобрено разрешение за достъп.
Изходната позиция е затворена. Флагът на тенанта, който управлява това, е включен по подразбиране за всяка клиентска организация; отворени остават само вътрешните и демо тенантите на Venvera. Без активно, одобрено разрешение опитът на инженер да отвори вашия тенант през пътя view-as се отказва - сесията изобщо не започва.
Това е правилното подразбиране за платформа, която държи данни за съответствие, но не може да е цялата история. Работата по поддръжката понякога изисква поглед върху реалния тенант.
Струва си да сме откровени за компромиса, защото той е реален. Затвореното подразбиране прави поддръжката по-бавна. Инженер, който иначе би хвърлил един поглед в тенанта, трябва да напише обосновка и да изчака някой от вашите хора да я прочете. Смятаме, че това е правилната цена за платформа, която държи регистъра ви на рисковете и записите ви за инциденти, но ако сравнявате доставчици, очаквайте тези с постоянен достъп да затварят някои тикети по-бързо. Решете кое от тези две качества всъщност искате от инструмент за съответствие.
Как работи временният достъп
Някои проблеми се възпроизвеждат само с вашите реални данни: бъг, който зависи от конкретна конфигурация, заседнал импорт, ключов индикатор за риск, който изчислява число, изглеждащо погрешно. За тези случаи Venvera има поток заявка-и-одобрение, изграден по модела на това, което облачните доставчици наричат customer lockbox. Той минава през четири етапа и вие държите бариерата на етап две.
Нищо на етапи три и четири не може да се случи, освен ако администратор на тенанта активно одобри на етап две. В рамките на този поток няма таймаут, който сам по себе си да дава достъп, няма ескалационен път, който да ви заобиколи, и няма начин заявяващият инженер да одобри собствената си заявка.
Какво трябва да поиска инженерът
Инженерът не може да заяви достъп тихомълком, широкообхватно или на едро. Формата за заявка го задължава да се ангажира писмено с три конкретни неща.
- Одобряващ. Един поименно посочен администратор от вашата организация. Инженерът избира реален човек, който работи при вас; платформата отхвърля пощенските кутии на Venvera, общите опашки на поддръжката и всеки, който няма админ роля във вашия тенант.
- Причина. Свободен текст от поне осем символа, съхранен така, както е написан. Одобряващият го вижда дума по дума и той се записва в одитната следа на вашия тенант като част от записа на заявката, така че мъглява или копирана причина остава видима за вас и остава на запис.
- Продължителност. Измерва се в минути и е ограничена до 1440, тоест 24 часа - наложено както от формата за заявка, така и от ограничение в базата данни. Ако работата продължи по-дълго, инженерът трябва да подаде нова заявка и вие одобрявате отново.
Когато заявката бъде подадена, избраният одобряващ получава известие. Никой друг не може да одобри вместо него, а инженерът все още няма достъп на този етап.
Причината да се посочва един човек вместо споделена опашка е без блясък. Опашки, които всеки може да разчиства, се разчистват от онзи, който най-малко вероятно ще прочете причината. Поименен одобряващ, който трябва да погледне писмената обосновка, е по-бавна бариера и значително по-добра.
Одобрение от дашборда или по имейл
Одобряващият може да действа по два начина. Вътре във Venvera заявката се появява на неговия дашборд и той я одобрява или отказва директно. Извън приложението получава имейл с еднократен линк и шестцифрен код. Отварянето на линка само по себе си е недостатъчно: одобряващият трябва да е влязъл във Venvera като себе си и след това да въведе кода. Тази двусъставна проверка означава, че автоматично кликащ пощенски скенер или линк, препратен към грешната пощенска кутия, не може да одобри нищо.
Защо два канала? Каналът през дашборда е бързият път за администратори, които вече работят във Venvera. Имейл каналът съществува, за да работи одобрението и когато одобряващият не е влязъл в системата, и той никога не отслабва проверката: кликването върху линк само по себе си не дава нищо.
Ограничен във времето и оттегляем във всеки момент
Одобреното разрешение е ограничено и в двата края.
| Типичен SaaS достъп за поддръжка | Достъп на инженер във Venvera |
|---|---|
| Поддръжката и инженерингът държат постоянен достъп до клиентските данни. Вие се доверявате на политика и обикновено не можете да видите кога този достъп се използва. | Без постоянен достъп. Всяко разрешение е една одобрена заявка с начало, изтичане и поименен одобряващ от вашата страна. |
| Веднъж даден, достъпът обикновено се задържа. Премахването му е ръчна поддържаща задача, която често не се случва. | Достъпът приключва сам. Сесията за преглед, която се издава на инженера, е ограничена до изтичането на разрешението, така че не може да бъде проточена извън прозореца, който сте одобрили. |
| Оттеглянето на достъпа означава да подадете тикет към доставчика и да чакате някой да го обработи. | Всеки администратор на тенанта, включително и такъв, различен от първоначалния одобряващ, може да оттегли активно разрешение незабавно от дашборда за достъп. |
Максимумът, който може да поиска една заявка, е 24 часа. По-кратко е нормално: едночасово разрешение за бързо възпроизвеждане е обичайно. Смисълът е, че достъпът има вграден край още от началото, вместо да разчита някой да си спомни да го отнеме.
Заявката и решенията по нея са във вашата одитна следа
Не се налага да приемате потока на доверие, защото заявката и всяко решение по нея се записват в одитната следа на вашия собствен тенант, до текущия статус на вашия дашборд за достъп.
- Първоначалната заявка, включително причината и продължителността, които са били поискани.
- Одобрението или отказът, включително през кой канал е направено, в приложението или по имейл.
- Оттеглянето, ако е имало такова, включително кой администратор на тенанта го е извършил.
Всяко разрешение носи собствено начално време, изтичане и поименен одобряващ, така че виждате точно кога се е отворил прозорец, кога се е затворил и кой го е разрешил. Това е запис на заявката и решенията по нея. Дашбордът за достъп на адрес /tenant-access показва чакащите, активните и приключилите заявки на едно място.
Защо това има значение за NIS2 и DORA
Ако управлявате програма за съответствие, достъпът на трети страни до вашите данни е нещо, което самите ви рамки ви задължават да управлявате. Съгласно NIS2 сигурността на веригата на доставки е изрично задължение. Съгласно DORA вашите ICT доставчици от трети страни и достъпът, който те държат, принадлежат на вашия Register of Information и на вашите договорености за надзор. ISO 27001 Annex A покрива отношенията с доставчиците и привилегирования достъп в същия дух.
Самата Venvera е ICT доставчик за своите клиенти. Описаният тук поток на одобрение е част от онова, което ви позволява да отговорите на въпросите за достъпа на доставчици в тези рамки с нещо конкретно: достъпът през пътя на поддръжката се отказва по подразбиране, дава се само по заявка, ограничен е във времето, оттегляем е и се записва при вас. Това е далеч по-силен отговор от абзац в политически документ на доставчик.
Задайте същия въпрос на всеки SaaS доставчик, който държи вашите регулирани данни, и обърнете внимание на формата на отговора. „Достъпът е ограничен до оторизиран персонал съгласно нашата политика за сигурност" описва намерение. Одобрение за всяка отделна заявка, което можете да видите, оттеглите и експортирате от собствената си одитна следа, описва контрол. Само едното от двете дава на оценителя нещо, което да провери с извадка.
Одиторът ще попита. „Как контролирате достъпа на вашите SaaS доставчици до вашите регулирани данни?" е нормален въпрос при оценка по NIS2 или DORA. Да можете да покажете поток на одобрение за всяка отделна заявка, ограничен във времето и записан в одитната следа, е чист отговор.
Какво покрива това и къде са границите му
Струва си да сме прецизни за границата на този контрол. Потокът на одобрение е процедурна бариера. Приложният слой на Venvera държи ключа за съответния тенант, нужен за работа с вашите данни, а одобрението на администратор на тенанта е това, което отваря пътя на поддръжката през този слой. Потокът гарантира, че този път е затворен по подразбиране, отваря се само с вашето изрично и записано съгласие и се затваря отново автоматично, когато прозорецът приключи.
Той не поставя ключа за декриптиране във вашите ръце. Ключ, държан от клиента, който дори служителите на Venvera не биха могли да използват, е различен контрол и този поток не претендира да го осигурява. Това, което потокът осигурява, е затворена по подразбиране, ограничена във времето, записана в одитната следа бариера за всяка отделна заявка върху достъпа на служители през пътя view-as на поддръжката.
Ако доставчик ви каже, че управляваните от клиента ключове правят достъпа на служители невъзможен, прочетете дребния шрифт за това кои операции продължават да се изпълняват вътре в тяхната платформа. Пазенето на ключове и управлението на достъпа са отделни контроли и повечето продукти, предлагащи първото, все още се нуждаят от второто. Предпочитаме да очертаем границата ясно, отколкото да си тръгнете с гаранция, която не сме дали.
За този път подразбирането остава в сила: данните на вашия тенант остават ваши и служителите на Venvera ги отварят само когато вие кажете, за толкова, за колкото кажете, със заявката и одобрението ѝ на запис.
