Важность безопасности репозитория данных невозможно переоценить, и любой администратор баз данных охотно поведает вам о бессонных ночах, проведенных в раздумьях о том, как защитить вверенную ему среду. Вместе с тем администраторы нередко приобретают негативную репутацию в своей компании. Это связано с тем, что они подчас затрудняют разработку, снижают производительность, нарушают стабильность экземпляров, которыми управляют, затевают рискованный или навязчивый мониторинг и т. д. В данной статье мы рассмотрим первую причину: затруднения, возникающие в процессе разработки. Как найти баланс, обеспечивая безопасную работу пользователей и в то же время помогая им сохранять данные и строить интеллектуальные решения на основе этих данных?
Принцип предоставления минимальных прав
Принцип предоставления минимальных прав, в сущности, означает, что любому процессу, пользователю или программе доступ к информации и ресурсам должен предоставляться только в пределах, необходимых для выполнения стоящей перед ними задачи. Другими словами, предоставляйте доступ только к объектам, необходимым конечному пользователю, и только определенным методам (INSERT, UPDATE, DELETE, SELECT). В Microsoft SQL Server предусмотрено множество способов сделать это. Можно предоставить индивидуальные права доступа к отдельным объектам по мере перераспределения обязанностей или разработки методов доступа. Это хирургически точный подход к реализации принципа предоставления минимальных прав. Но это и большое препятствие для групп разработчиков и бизнес-процессов. Каждый раз, когда создается новая хранимая процедура, администратор базы данных вынужден взаимодействовать с разработчиками, чтобы предоставить разрешения на выполнение одному или нескольким пользователям, которые нуждаются в правах для запуска хранимой процедуры, чтобы решать задачи, контролируемые через эту хранимую процедуру. Это добавляет лишний шаг к процессу разработки и препятствует гибкости проектирования.
Рассмотрим несколько способов реализации принципа предоставления минимальных прав.
1. Осторожность превыше эффективности
Как этот типичный подход выглядит в реальности?
Приведу пример: Кэш Мани — разработчик в компании CruiseCorp, и он умеет решительно продвигать свои инициативы. Кэш без проблем создает хранимые процедуры в «песочнице» компании — ему предоставлен необходимый доступ как раз для этих целей. Однако группа администраторов баз данных, возглавляемая Пейджем Сплитом, выполняет свою работу, наделяя исключительно администраторов правом выдавать разрешения не только в производственной среде, но и во всех средах данных компании CruiseCorp. Это означает, что каждый раз, когда Кэш создает новую хранимую процедуру, ему необходимо координировать свои действия с одним из администраторов баз данных группы Пейджа, чтобы запустить команду вроде следующей:
GRANT EXECUTE ON <эта_ужасная_ хранимая_ процедура> TO <определенному_пользователю>.
Преимущества
Данный метод безусловно позволяет реализовать принцип предоставления минимальных прав. Выдаются только необходимые разрешения, и безопасность контролируется администраторами баз данных, а не более широкой группой сотрудников.
Недостатки
Если требуется обеспечить обмен данными между группами пользователей в рамках гибкого процесса разработки, время выполнения проекта увеличивается. Представьте себе чрезвычайно эффективную и интенсивно используемую среду разработки, такую как среда компании CruiseCorp. Внедрение новых функций замедляется из-за вынужденного взаимодействия между сотрудниками, документирования на разных уровнях и согласования прав, предоставляемых для новой хранимой процедуры. Кроме того, группе администраторов баз данных доставляет неудобства постоянный поток запросов о предоставлении разрешений на выполнение, а нам известно, как администраторы баз данных не любят, когда их отвлекают.
2. Предоставление разрешений на выполнение на уровне схемы
Предоставляя разрешения на выполнение на уровне схемы определенному пользователю, вы наделяете его правом выполнять любую хранимую процедуру, которая существует или будет существовать в этой схеме. Таким образом, администратор баз данных перестает препятствовать процессу разработки, поскольку права назначаются неявно с упреждением. Синтаксис простой. Я рекомендую применять этот метод только в среде разработки. Сначала синтаксис:
GRANT EXECUTE ON SCHEMA:: <некоторая_схема> TO < некоторый_пользователь>;
После выполнения команды пользователь сможет запускать любую хранимую процедуру, принадлежащую конкретной схеме.
Преимущества
Администраторы баз данных исключены из процесса разработки, так как их работа на данном этапе выполнена. В то же время разработчикам не нужно беспокоиться о предоставлении прав — об этом позаботились. Двигайтесь вперед.
Недостатки
Представьте на секунду, что это означает в среде с широкомасштабными схемами, где каждый может загрузить и установить Microsoft SQL Server Management Studio за 10 минут через Интернет со скромной пропускной способностью: любые предохранительные меры можно обойти с помощью Microsoft SQL Server Management Studio, напрямую применяя хранимые процедуры к базе данных. Каждый, кто знает имя пользователя и пароль для базы данных или может получить доступ к строке подключения, имеет доступ к выполнению всех хранимых процедур, правами на которые обладает соответствующий пользователь. При этом все барьеры на прикладном уровне обходятся благодаря прямому обращению к объектам в Microsoft SQL Server Management Studio. Никогда не слушайте сторонних поставщиков и разработчиков внутри компании, утверждающих, что безопасность обеспечивается разделением приложений. Такая защита ненадежна: представьте, как просто установить Microsoft SQL Server Management Studio, определить связи серверов и баз данных и соответствующие пары «имя пользователя-пароль».
Кэш заинтересован только в том, чтобы пользователи с идентификатором, используемым клиентами для оформления заказов, могли просматривать свои предыдущие заказы с помощью новой хранимой процедуры. Он не подозревает, что теперь они имеют право на изменение записей о выставлении счетов, так как хранимая процедура для выставления счетов является частью схемы dbo, как и хранимая процедура для заказов. Такой метод годится для «песочниц», но я не рекомендую применять его в производственных условиях.
3. Предоставление контроля над схемой разработчикам
Недавно один из разработчиков, с которым я сотрудничаю, запросил разрешение db_owner в «песочнице» разработки, чтобы подобрать права для новых проектируемых хранимых процедур. Сказать, что я ответил уклончиво, значит, выразиться мягко. Помимо того что разработчикам разрешено предоставлять доступ, наличие у них прав db_owner повышает вероятность разнообразных негативных сценариев, от изменения типов данных в таблицах до удаления таблиц и удаления базы данных. Еще одна тема, которую я охотно поднимаю при обсуждении, — вопрос о дополнительном влиянии разрешений db_owner, предоставленных для одной базы данных, на другую базу данных в консолидированной среде. Владелец роли db_owner имеет полный контроль над размерами файлов базы данных. Это означает, что владелец роли db_owner может изменить размер файла журнала транзакций, заполнив все свободное пространство на томе, выделенное для ваших журналов транзакций. Когда такое происходит, результаты получаются плачевные. Поэтому своему коллеге в правах db_owner я категорически отказал.
С другой стороны, предоставление контроля над схемой позволяет владельцу прав управлять безопасностью схемы без негативных последствий. Да, изменения схемы по-прежнему разрешены, но никто не удалит базу данных и не заполнит том, содержащий журнал.
Синтаксис простой:
GRANT CONTROL ON SCHEMA:: < определенная_ схема> TO <определенному_пользователю>;
Преимущества
Мы возвращаемся к тому положению, когда администраторы баз данных уже не препятствуют обеспечению безопасности, и теперь у конечных пользователей есть права только на выполнение необходимых операций с объектами базы данных (при условии, что удастся удержать разработчиков в тех же рамках, в которых действуют администраторы баз данных). Разработчики не имеют прав, предоставляемых через db_owner, но все же их права шире, чем когда-либо раньше.
Недостатки
В сущности, удваивается число рабочих групп, оказывающих влияние на безопасность.
4. Сбалансированный подход
Я предпочитаю использовать гибридный вариант, когда модель GRANT CONTROL ON SCHEMA применяется к разработчикам в нашей «песочнице» или среде разработки в сочетании с предоставлением им прав в роли db_ddladmin. При переносе объектов в среду, приближенную к производственной, мы используем инструменты сравнения, такие как Redgate SQLCompare, для подготовки сценариев развертывания, охватывающих базовые права, необходимые для любых новых хранимых процедур. Таким образом достигается возможность быстрого размещения в тестовой среде или «песочнице», но строгого контроля при движении к производственному этапу. В итоге мы соблюдаем принцип предоставления минимальных прав в каждой среде, кроме среды начальной разработки, одновременно не препятствуя быстрому проектированию.