Для чего нужен владелец схемы в SQL?

Краткий ответ

Владелец схемы определяет authorization identifier, которому принадлежит пространство имён схемы и который получает права управления ею. Это не означает автоматически владение каждой таблицей или всеми объектами внутри схемы: правила владения объектами и делегирования прав зависят от конкретной СУБД.

Исторический контекст

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

В стандарте SQL схема связана с authorization identifier — идентификатором владельца. Конкретные модели ролей, наследования прав и возможности передачи владения различаются между СУБД.

Постановка проблемы

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

Неверное назначение владельца осложняет миграции и эксплуатацию: DDL может выполняться только от имени владельца или роли с соответствующими правами. Передача доступа к данным поэтому должна рассматриваться отдельно от передачи административного контроля над схемой.

Подробное решение

При создании схемы SQL связывает её с владельцем. Владелец обычно получает особый административный статус: может управлять схемой и, в зависимости от реализации, создавать или изменять объекты в ней, предоставлять права и отзывать их.

Минимальный пример:

CREATE SCHEMA reporting AUTHORIZATION report_owner;

CREATE TABLE reporting.daily_sales (
    sale_id INTEGER PRIMARY KEY,
    amount DECIMAL(12, 2) NOT NULL
);

Здесь report_owner — владелец схемы reporting. Но владельцем таблицы может стать субъект, от имени которого она фактически создана, если такая модель предусмотрена СУБД. Поэтому наличие права SELECT на reporting.daily_sales не следует путать с правом менять схему.

Схема также не является механизмом изоляции сама по себе. Пользователь может иметь доступ к объектам разных схем, а одна схема может содержать объекты, доступные разным ролям. Безопасность строится комбинацией владения, объектных привилегий и, в некоторых СУБД, прав на саму схему.

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

Ситуация из практики

Команда разворачивает отчётную схему. Вариант 1 — сделать владельцем схемы учётную запись приложения. Это упрощает миграции, но при компрометации приложения злоумышленник потенциально получает административный контроль над схемой.

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

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

Что кандидаты часто упускают

1. Достаточно ли права на таблицу, чтобы создать в схеме новую таблицу?

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

2. Становится ли владелец схемы владельцем всех объектов, созданных внутри неё?

Не обязательно. Схема и объекты имеют собственные правила владения. Владелец схемы может иметь расширенные права управления пространством имён, но создатель таблицы или представления может считаться владельцем самого объекта. Поэтому при проектировании миграций нужно явно учитывать, какая роль создаёт объекты и кто сможет впоследствии их изменять.

3. Можно ли считать схему границей безопасности между приложениями?

Нет. Схема прежде всего организует имена и объекты, а не автоматически изолирует данные. Пользовательские роли могут получить права сразу на несколько схем, а объектные привилегии могут разрешать доступ к отдельным таблицам. Надёжная изоляция требует явной настройки прав, а при необходимости — отдельных баз данных, владельцев, политик строкового доступа или других средств конкретной СУБД.