С какими механизмами встроенной защиты базы данных вы сталкивались?

Что проверяют

Знаете ли вы, что защита данных живёт в самой СУБД, а не только в коде приложения, и различаете ли аутентификацию, права и шифрование. Для бэкендера на Python это ещё и вопрос про то, под какой ролью в базу ходит ваш сервис.

Как отвечать

Стройте ответ по слоям, на примере той СУБД, с которой работали. Для PostgreSQL это выглядит так:

• кто подключается: настройки в pg_hba.conf, метод scram-sha-256, TLS до базы и sslmode=verify-full у клиента, а не require;
• что ему можно: роли и GRANT, права на уровне таблиц и отдельных колонок, своя роль приложению и своя миграциям, снятые лишние права с роли public;
• какие строки он видит: построчная безопасность, политики включаются через ALTER TABLE ... ENABLE ROW LEVEL SECURITY, а признак арендатора подставляется из параметра сессии;
• целостность: NOT NULL, CHECK, внешние ключи и уникальные индексы это тоже защита, только от кривых данных;
• хранение и наблюдение: шифрование диска, pgcrypto для отдельных колонок, журнал и расширение pgaudit для аудита, statement_timeout и лимит подключений против тяжёлых запросов.

Со стороны Python добавьте главное: запросы только с параметрами, cur.execute(sql, params) или связанные параметры в SQLAlchemy, склейка строк запрещена даже во внутренних скриптах.

Где спотыкаются

Считают, что ORM сам по себе защищает от инъекции. Защищают параметры, а не ORM: сырой фрагмент через text(), подстановка имени колонки в сортировку или ручная сборка шаблона для LIKE пробивают любой слой абстракции.

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

Третье: путают шифрование на диске с ограничением доступа. Оно спасает от украденного диска или утёкшего бэкапа, но клиент, подключившийся с валидным паролем, видит расшифрованные данные. Это разные угрозы и разные механизмы.