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

Принцип предоставления минимальных прав

Принцип предоставления минимальных прав, в сущности, означает, что любому процессу, пользователю или программе доступ к информации и ресурсам должен предоставляться только в пределах, необходимых для выполнения стоящей перед ними задачи. Другими словами, предоставляйте доступ только к объектам, необходимым конечному пользователю, и только определенным методам (INSERT, UPDATE, DELETE, SELECT). В Microsoft SQL Server предусмотрено множество способов сделать это. Можно предоставить индивидуальные права доступа к отдельным объектам по мере перераспределения обязанностей или разработки методов доступа. Это хирургически точный подход к реализации принципа предоставления минимальных прав. Но это и большое препятствие для групп разработчиков и бизнес-процессов. Каждый раз, когда создается новая хранимая процедура, администратор базы данных вынужден взаимодействовать с разработчиками, чтобы предоставить разрешения на выполнение одному или нескольким пользователям, которые нуждаются в правах для запуска хранимой процедуры, чтобы решать задачи, контролируемые через эту хранимую процедуру. Это добавляет лишний шаг к процессу разработки и препятствует гибкости проектирования.

Рассмотрим несколько способов реализации принципа предоставления минимальных прав.

1. Осторожность превыше эффективности

Как этот типичный подход выглядит в реальности?

Приведу пример: Кэш Мани — разработчик в компании CruiseCorp, и он умеет решительно продвигать свои инициативы. Кэш без проблем создает хранимые процедуры в «песочнице» компании — ему предоставлен необходимый доступ как раз для этих целей. Однако группа администраторов баз данных, возглавляемая Пейджем Сплитом, выполняет свою работу, наделяя исключительно администраторов правом выдавать разрешения не только в производственной среде, но и во всех средах данных компании CruiseCorp. Это означает, что каждый раз, когда Кэш создает новую хранимую процедуру, ему необходимо координировать свои действия с одним из администраторов баз данных группы Пейджа, чтобы запустить команду вроде следующей:

GRANT EXECUTE ON
   <эта_ужасная_ хранимая_ процедура>
   TO <определенному_пользователю>.

Преимущества

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

Недостатки

Если требуется обеспечить обмен данными между группами пользователей в рамках гибкого процесса разработки, время выполнения проекта увеличивается. Представьте себе чрезвычайно эффективную и интенсивно используемую среду разработки, такую как среда компании CruiseCorp. Внедрение новых функций замедляется из-за вынужденного взаимодействия между сотрудниками, документирования на разных уровнях и согласования прав, предоставляемых для новой хранимой процедуры. Кроме того, группе администраторов баз данных доставляет неудобства постоянный поток запросов о предоставлении...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.
Купить номер с этой статьей в PDF