Как прекомерните права в базата данни разширяват пробива

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

Отправната точка: допускаме, че контейнерът е компрометиран

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

Стъпка 1 — Тайни в открит вид по време на изпълнение

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

Урокът: внасяйте тайните в последния възможен момент, дръжте ги извън широката среда на процеса и предпочитайте краткотрайни, посредничени данни за достъп пред статични, вградени в конфигурацията.

Стъпка 2 — Акаунтът към базата данни беше суперпотребител на целия клъстер

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

Един компрометиран уеб процес никога не бива да може да чете данните на друга клиентска организация, камо ли на всяка клиентска организация. Акаунтът на приложението трябва да има точно правата, които приложението изисква, точно върху данните, които притежава — нищо повече.

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

Стъпка 3 — Ключът за подписване позволяваше подправяне на сесии

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

Урок: защитете правото за подписване според модела на заплаха. Система за тайни контролира съхранението и предоставянето, но може да връща ключа на разрешено приложение; HSM или услуга за подписване може да държи поддържаните частни ключове неизнасяеми. При разкриване ограничете компрометирането, заменете ключа, прекратете приемането на стария и обезсилете засегнатите сесии според случая. Самата ротация не премахва достъпа на нападателя.

Стъпка 4 — Още ключове в същата конфигурация

Същата четима конфигурация съдържаше и GitOps ключ за внедряване (път обратно към веригата за доставка на софтуер) и защитени с парола ключове за прехвърляне на файлове към партньори — чиито пароли, разбира се, бяха в същия файл. Добрата верига рядко спира при първата награда; тя продължава да дърпа нишките, докато нещо структурно не я спре. Тук нищо не го направи, докато ние не избрахме да спрем.

Как да ограничите обхвата на пораженията

• Минимални необходими права на нивото на данните. Нито един акаунт на приложение не бива да е суперпотребител на базата данни. Ограничете го до данните, които притежава.
• Сегментирайте базата данни в мрежата. Достижима само от хостовете на приложението ѝ, никога широко.
• Тайни — късно и краткотрайни. Внасяйте ги по време на работа, дръжте ги извън широката среда на процеса, предпочитайте посредничени и временни данни за достъп.
• Ключовете за подписване в HSM или система за управление на тайни, с подмяна от една стъпка.
• Допускайте, че контейнерът пада. Проектирайте така, че един компрометиран процес да е ограничен инцидент, а не такъв за цялата компания.

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

Спасява ли ви управлявана облачна база данни?

Отчасти — и не по начина, по който екипите се надяват. Управляваната услуга за база данни премахва операционната система на хоста от уравнението, така че конкретната стъпка „изпълнение на команди върху хоста на базата данни“ става много по-трудна. Но ключовият момент в цялата верига — акаунт на приложението с много повече права, отколкото приложението изисква — остава непроменена и дори е по-лесно да бъде конфигуриран неправилно, защото осигуряването на мощна роля е едно щракване. Все още рутинно намираме данни за достъп на приложения в управлявани среди, които могат да четат и записват през всяка клиентска организация и всяка схема. Управляваните услуги преместват пода; те не преместват тавана. Минималните необходими права на нивото на данните все още са контролът, който ограничава обхвата на пораженията, в облака или не.

Как изглежда злоупотребата на нивото на данните във вашите журнали

Ограничаването на обхвата на пораженията е предотвратяване; улавянето на злоупотребата е откриване и двете вървят заедно. Сигналите са конкретни и ценни: акаунт на приложение, използван от неочакван хост, влизане на суперпотребител извън периодите за поддръжка, масови прочитания, които прекосяват границите между клиентски организации, или внезапен скок в броя на върнатите записи. Известявайте за тези модели на нивото на данните, не само на периметъра. Колкото по-рано забележите една опорна точка да посяга към целия набор от данни, толкова по-малък е инцидентът — а разликата между ограничено събитие и уведомление за пробив често е минути.

Проектиране на роли с минимални права за всяка схема и всяка клиентска организация

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

Разделете идентичностите за миграции, работа на приложението и отчети. Дайте на runtime ролята само необходимите права за таблици, последователности и функции; избягвайте superuser, BYPASSRLS, излишно създаване на схеми и привилегировано изпълнение на файлове или програми. Четенето на системни каталози на PostgreSQL не е забранено по принцип: обичайните справки подпомагат нормалната работа. Прегледайте ефективните права, включително наследените и предоставените на PUBLIC.

RLS може да ограничи ефекта от пропуснат приложен филтър, когато политиката използва доверен контекст. Той не изолира компрометирана runtime роля, ако тя може да избира чужд контекст или да заобикаля политиката. Проверете правата за задаване на контекст, собствеността на таблиците, BYPASSRLS и изчистването на контекста при повторно използване на връзки. Отделната схема за всяка организация също изисква подходящи права; различните имена не спират общ привилегирован профил.

Ограничаване на мрежовия достъп до слоя с данни

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

Използвайте частна свързаност и ограничен входящ достъп, когато е подходящо, само за необходимите приложни и административни пътища. DNS видимостта и мрежовата достижимост са различни: частно име може да се разрешава и извън приложната мрежа. Ограничете и наблюдавайте ненужния egress, но не го приемайте за пълна защита срещу извеждане през разрешен приложен път. Административният слой изисква собствена политика за идентичности и мрежа.

Предоставяне на тайни по време на изпълнение и проблемът с първоначалния достъп

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

Идентичността на работното натоварване може да премахне съхранена първоначална тайна, но възможността за копиране и повторно използване зависи от механизма. Издадените от платформата bearer токени могат да бъдат копирани в срока им на валидност. Когато е подходящо, използвайте credentials с ограничен получател или механизъм за доказване на притежание и ограничете какво може да заявява компрометирано приложение.

Обвиващо шифроване (envelope encryption) с KMS или HSM

Обвиващото шифроване използва ключ за данни (DEK) и ключ, който защитава DEK (KEK). KMS или HSM може да контролира поддържани операции с KEK, без да изнася ключовия материал. Разрешено приложение може да получи и кешира открит DEK, затова не всяко дешифриране създава KMS заявка. Проектирайте заедно срока на ключовете, кеширането и правата за дешифриране.

Обвиващото шифроване може да защити копие само на базата, когато нападателят няма използваеми ключове или право за дешифриране в KMS. Това е различно от описаното компрометиране на приложния контейнер: приложението може да запази разрешения достъп за дешифриране или кеширани ключове. Одитните събития подпомагат откриването и разследването, но не доказват предотвратено разкриване. Преобвиването на съществуващи ключове е отделна операция от автоматичната ротация в KMS; нито една не възстановява тайната на вече разкрити данни.

Откраднати credentials само за базата
   -> копие: шифровани данни + обвит DEK
   -> за дешифриране трябват ключове или право в KMS

Компрометирано приложение
   -> може да запази право за дешифриране или кеширани ключове
   -> журналите подпомагат разследването, не доказват защита