🗄️ SQL и базы данных · 20 вопросов · ~42 мин · ⏱ Таймер 42:00 · Сложный · 👥 1 прошёл

Безопасность базы данных

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

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 42 минут. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого задания.

Вопрос 1 из 20

Почему веб-приложению не следует подключаться суперпользователем?

Пул соединений не может повторно использовать сеансы суперпользователя Суперпользователь может выполнять DDL, но не прикладные SELECT и UPDATE Суперпользователь не имеет доступа к пользовательским таблицам без отдельного GRANT Любая уязвимость приложения получит полномочия обходить почти все ограничения базы

Вопрос 2 из 20

Как разумно разделить роли?

-- owner/migrator создаёт объекты
-- app_runtime получает только нужные GRANT

Приложению владеть всеми схемами Владелец для миграций, отдельная ограниченная роль для приложения Создавать отдельного суперпользователя на каждый запрос и удалять его после COMMIT Одна общая роль postgres для всех сред

Вопрос 3 из 20

Что означает атрибут NOLOGIN у роли?

CREATE ROLE report_reader NOLOGIN;

К роли можно подключиться без пароля, если она включена в другую роль Вход запрещён, но роль может хранить права для участников Роль не может хранить привилегии, пока ей не разрешён LOGIN Роль действует только внутри транзакции и исчезает после COMMIT

Вопрос 4 из 20

Почему владелец таблицы опаснее обычного пользователя с SELECT, INSERT, UPDATE?

Владелец отличается от роли с DML только правом менять комментарий к таблице Владелец может менять права, но не имеет права читать собственную таблицу Владелец может менять объект и распоряжаться его правами, а не только работать с данными Владелец отличается только способом аутентификации, а права на объект те же

Вопрос 5 из 20

Что проверить при GRANT report_reader TO analyst?

GRANT report_reader TO analyst;

Порядок строк в отчёте, потому что GRANT меняет сортировку результата Наследование прав и возможность SET ROLE Только совпадение имени роли с названием таблицы users Размер WAL: членство в роли зависит от объёма журнала предзаписи

Вопрос 6 из 20

Как выдать только чтение таблицы orders?

GRANT ALL ON DATABASE app TO report_reader; GRANT UPDATE ON TABLE orders TO report_reader; GRANT SELECT ON TABLE orders TO report_reader; ALTER ROLE report_reader SUPERUSER;

Вопрос 7 из 20

Почему GRANT SELECT ON orders может быть недостаточен для роли в отдельной схеме sales?

GRANT USAGE ON SCHEMA sales TO report_reader;
GRANT SELECT ON sales.orders TO report_reader;

Любой доступ к объекту вне public возможен только суперпользователю Для чтения таблицы в отдельной схеме дополнительно требуется право DELETE на неё Ей также может понадобиться USAGE на схему sales Право SELECT на таблицу неявно включает доступ к её схеме

Вопрос 8 из 20

Как отозвать ранее выданное изменение данных?

REVOKE UPDATE ON sales.orders FROM analyst; DELETE UPDATE FROM analyst; DENY UPDATE sales.orders; GRANT NO UPDATE ON sales.orders;

Вопрос 9 из 20

Почему после выдачи SELECT ON ALL TABLES IN SCHEMA новые таблицы могут остаться недоступны?

GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO report_reader;

GRANT охватывает существующие таблицы, но не задаёт права для объектов, созданных позже USAGE на схему автоматически даёт SELECT на все будущие таблицы этой схемы ALL TABLES задаёт постоянное правило, которое применяется к любой таблице, созданной позже Новая таблица наследует привилегии от последней созданной таблицы того же владельца

Вопрос 10 из 20

Зачем приложению может понадобиться USAGE на sequence?

GRANT USAGE ON SEQUENCE orders_id_seq TO app_runtime;

Чтобы читать строки таблицы, чей DEFAULT обращается к этой последовательности Для получения значений используемой последовательности Чтобы USAGE на последовательность автоматически дал INSERT в связанную таблицу Чтобы менять значение через setval и владельца последовательности без дополнительных прав

Вопрос 11 из 20

Где не следует хранить пароль базы?

В исходном коде и репозитории проекта В выдаваемом платформой краткоживущем токене В специализированном хранилище секретов с ограниченным доступом В защищённой переменной среды процесса, если управление окружением надёжно

Вопрос 12 из 20

Почему файл .env, исключённый из Git, всё равно не является полной стратегией секретов?

Нужно контролировать права файла, резервные копии, передачу, ротацию и доступ каждого окружения Файл .env решает весь жизненный цикл секрета, если приложение читает его только при запуске Достаточно зашифровать .env ключом, который хранится рядом с ним в том же развёртывании Локальный файл сам по себе гарантирует изоляцию секрета от других процессов и резервных копий

Вопрос 13 из 20

Что делать после подтверждённой утечки пароля?

Удалить сообщение с секретом; после этого прежнее значение снова можно считать закрытым Переименовать переменную подключения, сохранив то же раскрытое значение Дождаться плановой ротации, если в журналах пока нет подтверждённого входа Отозвать или сменить учётные данные, проверить журналы, устранить канал и обновить зависимые службы

Вопрос 14 из 20

Почему пароль аналитика не стоит использовать в рабочем приложении?

Общие учётные данные удобнее: достаточно одной ротации для всех потребителей Разные назначения требуют разных прав, сроков жизни и независимой ротации Аналитическую роль можно использовать, если приложение читает те же таблицы Общая роль упрощает отзыв доступа: достаточно заменить один пароль для всех потребителей

Вопрос 15 из 20

Что даёт проверка TLS-сертификата сервера?

sslmode=verify-full

Проверка сертификата одновременно подтверждает SQL-права подключившейся роли Проверенный сертификат заменяет аутентификацию роли базы данных Защищает от подключения к подменённому серверу verify-full подтверждает имя сервера, но само соединение после проверки остаётся незашифрованным

Вопрос 16 из 20

Какой журнал полезнее для расследования изменения прав?

Список объектов и индексов без автора, времени и результата действия Полный снимок содержимого базы после каждого чтения системного каталога Журнал средней длительности запросов и числа подключений по часам Время, роль, объект, действие GRANT/REVOKE, результат и источник соединения

Вопрос 17 из 20

Почему log_statement = all может быть опасен без дополнительных мер?

ALTER SYSTEM SET log_statement = 'all';

Параметры протокола и текст динамического SQL не могут попасть ни в один журнал Полное журналирование автоматически маскирует строковые литералы и параметры запросов В журнал могут попасть данные и секреты из SQL В режиме all записываются только операторы, завершившиеся ошибкой

Вопрос 18 из 20

Как аудитировать конечного пользователя, если все запросы идут одной ролью app_runtime?

Создать отдельного суперпользователя базы на каждого посетителя приложения Считать все действия принадлежащими администратору базы, раз техническая роль одна Определять конечного пользователя по последнему ORDER BY в его запросе Передавать проверяемый идентификатор в контексте сеанса/запроса и писать его в прикладной аудит вместе с транзакцией

Вопрос 19 из 20

Почему таблицу аудита нельзя разрешать UPDATE и DELETE рабочей роли?

REVOKE UPDATE, DELETE ON audit_log FROM app_runtime;

Аудит нельзя хранить в таблице, потому что журналы допустимы только в файлах Приложение сможет переписать следы своих действий Без PRIMARY KEY PostgreSQL автоматически разрешает рабочей роли удалять аудит Запрет UPDATE нужен лишь для ускорения SELECT по журналу

Вопрос 20 из 20

Как выбрать срок хранения журналов?

Удалять журналы сразу после COMMIT, раз операция уже завершилась По целям расследования, требованиям закона, объёму и риску хранения чувствительных данных Срок журналов следует приравнять к сроку хранения ежедневных резервных копий Хранить бессрочно: дополнительный объём и чувствительность данных не влияют на риск

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу