Реализация программы по ведению журнала безопасности и мониторингу базы данных (часть 3)

Сертификация GIAC (GCIA) Gold

Автор: Джим Хорват (Jim Horwath), jim.horwath@rcn.com

Консультант: Родни Кодл (Rodney Caudle)

Предыдущие части статьи:

Часть 1

Часть 2

6.2 Области планирования шифрования

Компании необходимо тщательно исследовать нужды бизнеса и последствия от реализации шифрования базы данных. Следует проанализировать четыре области перед внедрением шифрования. Первая и самая важная область - управление ключами. Управление ключами критически важно, поскольку зашифрованные данные бесполезны до тех пор, пока их не расшифруют. В компании должны быть прописаны политики и процедуры для нормального функционирования бизнеса, создания и восстановления резервных копий и эффективного управления ключами. Ошибки управления могут привести к потере данных компании и, соответственно, поставить под угрозу непрерывность бизнес-процессов. Компаниям следует регулярно проводить тестирование программ управления ключами в различных ситуациях для того, чтобы удостовериться в эффективности этих программ при различных условиях. Если компания потеряет ключи шифрования, то не сможет расшифровать данные, что сделает их бесполезными и поставит под угрозу существование всего бизнеса. В компаниях, использующих несколько платформ, задача управления ключами еще более сложна, поскольку у каждого поставщика есть свои особенности в реализации встроенного механизма шифрования. Вторая область, касающаяся шифрования базы данных, относится к качеству реализации программного обеспечения. Вполне очевидно, что приложениям необходимо считывать и записывать данные, иначе пользоваться этими приложениями не имеет никакого смысла. Шифрование колонок в таблице, вполне вероятно, может снизить производительность приложений. Третья область: в компаниях должны быть прописаны политики и процедуры, управляющие использованием и жизненным циклом ключей и шифрования. Внедрение политики шифрования скажется на обработке информации на протяжении всего жизненного цикла. Сюда относится непосредственное использование данных, создание и восстановление резервных копий, планирование непрерывности бизнес-процессов и аварийное восстановление. Все жизненные циклы бизнеса должны соответствовать политикам и процедурам. И, наконец, четвертая область касается вопросов производительности. В настоящее время многие бизнесы находятся в высоко конкурентной среде, и современному обществу все нужно «здесь и сейчас». Вследствие этого, падение производительности и неудовлетворение потребностей конечных пользователей может погубить бизнес. Шифрование первичных ключей или индексов скажется на производительности, поскольку окажет влияние на сортировку и скорость выполнения запросов. Если проблема производительности достаточно серьезна, то она может повлиять на прибыль и репутацию компании. Кто захочет вести бизнес с веб-сайтом, который медленно работает? Зашифрованные колонки занимают больше места на диске и увеличивают нагрузку на процессор. Компании должны выяснить, какие данные (колонки/индексы/таблицы и т. д.) необходимо шифровать и прикинуть общую стоимость шифрования данных. Внедрение шифрования базы данных без исследования, тестирования и подготовки весьма вероятно закончится провалом (Ottman, 2010, см. Раздел Ссылки).

6.3 Типы ключей

Ключи играют ключевую роль при шифровании базы. SQL Server может использовать три типа ключей: симметричные, асимметричные и сертификаты. Тип используемого ключа зависит от нужд бизнеса, требований приложений, допусков увеличения дискового пространства и критериев производительности (Microsoft, 2012, см. Раздел Ссылки).

6.3.1 Симметричные ключи

При шифровании симметричным ключом используется один и тот же ключ для шифровки и дешифровки данных. Вследствие этого симметричные ключи довольно трудно защитить. По рекомендации Microsoft защита ключа и SQL Server следует проводить при помощи подручных средств. Использование симметричных ключей позволяет добиться лучшей производительности, чем в случае использования асимметричных ключей и сертификатов. Симметричные ключи – хорошее решение, если шифрование данных, пока они находятся в базе, - единственное требование к шифрованию. Если данные, получаемые из базы, могут храниться и извлекаться как простой текст, симметричные ключи - хорошее решение, поскольку процесс шифровки и дешифровки при помощи симметричных ключей довольно быстр.

6.3.2 Асимметричные ключи

Асимметричных ключей всегда два, один предназначен для шифровки данных, второй – для дешифровки. Асимметричное шифрование потребляет больше ресурсов, чем симметричное, но зато является более защищенным. Асимметричные ключи не используют общий секрет, однако от хозяина секретного ключа требуется хранить его в тайне. Часто симметричные ключи используют асимметричный ключ для защиты перед сохранением симметричного ключа в базе данных. Асимметричные ключи хороши в тех случаях, когда информация используется совместно между несколькими приложениями и базой данных на SQL Server. Приложения используют публичный ключ для шифровки данных, которые потом отсылаются в базу данных. SQL Server защищает секретный ключ, используемый для дешифровки данных.

6.3.3 Сертификаты

Сертификаты – еще одна форма асимметричного шифрования, представляющего собой цифровую подпись, которая связывает публичный и секретный ключи с личностью. Сертификаты влияют на доверительные отношения: если Джим доверяет Родни и Родни доверяет Джо, то Джим доверяет Джо. У сертификатов есть дата истечения срока, и компании могут заканчивать срок действия сертификата, тем самым разрывая связь между публичным ключом и определенной личностью. Использование сертификатов уместно, когда есть необходимость использовать симметричное шифрование и нужно связать ключ с пользователем или группой пользователей. К примеру, если необходимо шифровать и дешифровать данные вне компании, сертификат поможет узнать, кто зашифровал данные.

6.4 Уровни шифрования SQL Server

В SQL Server реализовано два уровня шифрования: уровень базы данных и уровень ячейки. По- другому полное шифрование базы именуется Microsoft как прозрачное шифрование данных (Transparent Data Encryption, TDE). Когда же речь заходит о шифровании на уровне ячейки, то имеется ввиду шифрование отдельных колонок в таблице. По сравнению с прозрачным шифрование, шифрование на уровне ячейки позволяет полностью контролировать и отбирать только те данные, которые необходимо зашифровать. Информация, зашифрованная на уровне ячейки, находится в зашифрованном состоянии в памяти, за исключением случаев, когда данные расшифрованы. Алгоритм шифрования использует «соленое» значение, означающее, что если одинаковые данные зашифровать дважды, то на выходе будут разные результаты. Такой механизм предотвращает анализ шифротекстов, но в то же время мешает эффективному поиску зашифрованных данных. При использовании «соления» во время шифрования выходные данные принимают случайных характер, что делает невозможным их индексацию и приводит к проблемам с производительностью. Проблемы с производительностью появляются тогда, когда происходит шифрование первичного ключа или индексного поля в базе данных. При дешифровке на уровне ячейки требуется анализ тех данных, которые предназначены для шифровки. И, наконец, у функций шифрования на уровне ячейки есть лимит в 8000 байт на те данные, которые возвращают эти функции (DamirB, 2012, см. Раздел Ссылки).

При прозрачном шифровании происходит шифрование всей базы, и нет необходимости вносить изменения в приложение. База данных и файлы журналов шифруются во время нахождения на диске и дешифруются при считывании их в память. Информация шифруется на уровне странице перед записью данных на диск и дешифруется при считывании в память. При прозрачном шифровании не происходит дополнительно раздувания размеров уже зашифрованной базы, и используется асимметричный ключ, который хранится в блоке начальной загрузки базы данных (database boot record) и называется ключом шифрования базы данных (database encryption key, DEK). SQL Server защищает DEK, используя сертификат, который хранится в базе данных master и защищается модулем EKM (Extensible Key Management, расширяемое управление ключей). Прозрачное шифрование может помочь при защите в те периоды, когда данные уязвимы, например, на лентах с резервными копиями (Cristofor, 2007, см. Раздел Ссылки).

Шифрование требует значительных затрат ресурсов процессора. Необходимо тщательно подойти к вопросам планирования и исследования нужд бизнеса перед внедрением этого механизма. С точки зрения бизнеса необходимо взвесить все факторы: нормативные требования, локальные политики и какое влияние окажет шифрование на конечных пользователей. Разработчикам следует избегать шифрования первичных ключей и индексных полей, поскольку это приведет к замедлению сортировки и увеличит время ответа на запросы. Шифрование базы данных может увеличить ее размеры от 3 до 5 процентов от первоначального размера (DamirB, 2012, см. Раздел Ссылки).

6.5 Управление ключами

Шифрование базы данных может добавить дополнительный уровень защиты конфиденциальных данных, однако перед внедрением компания должна понимать, как шифрование повлияет на выполнение ежедневных операций. Наиболее важный вопрос: местонахождение и хранение ключей, используемых для шифровки и дешифровки данных. Частью программы по управлению ключами должно быть ведение журнала и просмотр как доступа к ключам, так и работы механизма защиты ключей. Управление ключами – сложная тема, которая требует глубокого понимания жизненного цикла ключей, а также их защиты и управления. Полноценная программа должна содержать план по восстановлению потерянных ключей и план по восстановлению информации в случае утери или удаления ключей. Незаслуженно забытая область – восстановление старой информации, когда ключи, возможно, уже не используются в работе. Возможность восстановления старой информация должно быть частью плана по поддержанию непрерывности бизнес-процессов. Если в компании есть инфраструктура открытых ключей (Public Key Infrastructure, PKI), возможно ли при помощи нее управлять ключами базы данных? Система PKI может помочь в защите и управлении ключами базы. Один важный вопрос: как внедрение шифрования повлияет на работу с резервными копиями. Если данные настолько важны, что их нужно шифровать, резервные копии также необходимо шифровать. Это защитит резервную копию, если она находится вне компании. Если в политике прописана периодическая смена ключей, должны быть предприняты меры по сохранению старых ключей, позволяющих по необходимости восстановить старые резервные копии. Существуют случаи нарушения работы компании из-за утери ключей для резервных копий, или была необходимость в восстановлении базы, но из-за потери ключей этого сделать не удалось.

Существует много проблем, связанных с механизмом шифрования, который должен соответствовать политикам и процедурам компании перед началом внедрения. Для успешной реализации этой программы требуется тщательный анализ и планирование последовательности действий. В корпорациях должны быть политики и процедуры, где прописана технология управления ключами. Кроме того, следует провести тщательное исследование данных для того, чтобы определить разумность использования шифрования и затраченные на это средства. Если есть необходимость в создании надежной защиты, шифрование может помочь вместе с вдумчивым планированием. Шифрование весьма ресурсозатратно, поскольку интенсивно использует процессор и дисковый накопитель. Регулярное ведение журнала и отслеживание доступа к ключам должно стать частью программы по реализации программы шифрования данных. Проверьте, действительно ли ваша компания нуждается в использовании шифрования, и оцените объемы данных, которые нужно шифровать.

7. Примеры использования

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

7.1 Использование и злоупотребление привилегиями

Первые три случая связаны с использованием и злоупотреблением привилегиями. В этом разделе будут затронуты случаи злоупотребления чрезмерными привилегиями доступа, злоупотребления легитимными привилегиями доступа и превышения привилегий доступа. Часто злоупотребление чрезмерными привилегиями доступа результат того, что у пользовательской учетной записи есть привилегии, выходящие за рамки их рабочих обязанностей. Довольно часто администраторы баз данных, ответственные за назначение привилегий, из-за недостатка рабочего времени будут выдавать одинаковый доступ для всех пользователей. Избыточные привилегии и недостаточный контроль в этой области – следствие отсутствие знаний или отсутствие желания получить знания по вопросам механизмов защиты, служебных обязанностей и доступа к информации. Модели механизмов защиты, служебные обязанности и доступ к данным – сложная тема, которая, как правило, охватывает многие отрасли знаний и дисциплины. Для повышения уровня безопасности в аудит привилегий следует внедрять дополнительные механизмы. Управление правами доступа – и так непростая тема, а взаимодействие операционной системы и механизмов защиты баз данных делает эту область еще более сложной. Компаниям следует иметь представление о механизмах защиты и отношения между данными наряду с задокументированной процедурой утверждения выдачи и отмены привилегий (Natan, 2005, см. Раздел Ссылки).

Наилучшее решение для снижения вероятности злоупотребления привилегиями – ограничение доступа в совокупности с контролем над доступом на уровне запросов путем ограничения до минимума прав на выполнение SQL-запросов и операций с данными. Это случай реализации принципа выдачи наименьших возможных привилегий. Контроль должен осуществляться над конкретными строками и столбцами внутри таблицы. Это позволит отследить учетные записи, которые пытаются получить доступ к данным, выходящим за рамки их уровня привилегий. Реализация этого принципа позволит защититься от многих наиболее распространенных уязвимостей баз данных. Решение о том, каким пользователям и группам будут доступны определенные данные, следует принимать во время разработки архитектуры программного обеспечения. Это поможет разработчикам и администраторам прикинуть, какие необходимы уровни доступа к информации. Как только приложение запустили в рабочую среду, контролировать доступ к данным будет намного проще, поскольку все будут знать свои права и обязанности. Принцип контроля над доступом на уровне запросов будет рассмотрен во время дискуссий о других уязвимостях (OWASP, 2012, см. Раздел Ссылки).

Создание отчетов о правах доступа – еще один элемент контроля, используемый при аудите доступа к приложениям и базам данных. Если право доступа требует одобрения руководства через систему билетов, добавление, приостановку, удаление и изменение соответствующих прав доступа следует указать в отчете о правах доступа. Отдел по контролю над правами доступа может проверять запросы и утверждения по каждому добавленному, отмененному или измененному праву доступа. При наличии расхождений между отчетом о правах доступа и запросами потребуется расследование и внесение корректировок.

Пример отчета о правах доступа

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

Внутри приложения может быть ограничен доступ к информации о покупателях в случае, если это запрещено в законах, нормативных правилах или политике безопасности, и сотрудники могут подключиться к базе при помощи инструментов Microsoft Office и загружать информацию на свой личный ноутбук. Сотрудники могут рассуждать так, что этот способ повысит их производительность, и они смогут выполнить свою работу быстрее и, по их мнению, эффективнее. Сотрудники не осознают того, что теперь загруженные ими данные стали уязвимыми, и если на ноутбук попадет вредоносная программа, или он окажется в руках злоумышленников, возникает угроза утечки информации. К тому же, существуют сотрудники, которые воруют данные для получения личной выгоды. Естественно, существует риск того, что администратор окажется мошенником и будет раздавать права кому попало или займется воровством информации (Shulman, 2006, см. Раздел Ссылки).

Наличие у владельцев бизнеса и сотрудников, отвечающих за аудит и контроль прав доступа, возможности просматривать транзакции и информацию о доступе к данным может помочь в защите информации и компании в целом. Связка из людей, процессов и технологий станет выигрышной на поприще борьбы с кражей информации и злоупотребления легитимными правами доступа. Ниже показан отчет, который демонстрирует реализацию процесса, основанного на политике аудита транзакций, связанных с конфиденциальной информацией. В отчете есть три строки, представляющие для нас интерес. Первая строка: кто осуществлял доступ к информации о номерах социального страхования (SSN) внутри приложения. Отчет показывает, что к SSN-номерам осуществлялся доступ 33 раза. Это означает не количество записей, а количество отдельных транзакций. Владельцу бизнеса следует знать, является ли такая активность нормальной, и если это не так, то провести расследование и выяснение обстоятельств, при которых осуществлялся доступ к данным. Вторая строка: 10 раз передавался большой объем информации. Передача большого объема данных может быть нормальным при работе приложения. Однако если владелец бизнеса считает такую активность ненормальной, это повод провести расследование. Третья строка указывает на выдачу привилегий. В данном случае сотрудник с высоким уровнем привилегий взял на себя полномочия администратора. Процесс выдачи привилегий следует сделать как можно более прозрачным с регистрацией этого события в журнале и пометкой о разрешении на выдачу. Должна быть возможность отследить всю цепочку, начиная от первоначального запроса на выдачу прав и до фактической их выдачи.

Отчет о доступе к конфиденциальным данным

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

Третья форма злоупотребления привилегиями – превышение привилегий доступа. Такое происходит, когда злоумышленник, используя уязвимость, увеличивает уровень своих полномочий до администратора или привилегированного пользователя. Уязвимости баз данных могут быть во многих местах: сохраненных процедурах, протоколах, SQL-выражениях, в коде платформы или операционной системе. Подобные виды атак трудно отследить, поскольку работа ведется от имени легальных пользователей, и отсутствует какая-либо подозрительная активность. Пользуясь этим, злоумышленники могут эксплуатировать уязвимость и повышать свои привилегии. Как только привилегии повышены, злоумышленник может украсть данные, изменять или отключать настройки безопасности, создавать или удалять учетные записи, добавлять вредоносный код и т. д. (Natan, 2005, см. Раздел Ссылки).

При помощи контроля над доступом на уровне запросов, можно минимизировать последствия от осуществления подобного типа атак. Однако если злоумышленник повысил свои привилегии до уровня суперпользователя и, соответственно, завладел всей системой, - контроль на уровне запросов не поможет. Операционная систему и базу данных следует подвергнуть дополнительному тестированию и защите, воспользовавшись услугами таких организаций как CIS, NIST или OWASP. После реализации дополнительных мер безопасности необходимо проверить нет ли конфликтов с бизнес-процессами или приложениями. Если в компании есть средства защиты (например, IDS или IPS), то они могут помочь в обнаружении и, возможно, в предотвращении атак, направленных на повышение привилегий доступа. Мониторинг доступа к базе данных в сочетании с мониторингом системных журналов операционной системы может помочь в обнаружении некоторых типов атак, направленных на повышение привилегий доступа (OWASP, 2012, см. Раздел Ссылки).

7.2 Слабая аутентификация

Механизм аутентификации – критическое звено в любой модели безопасности. Без аутентификации невозможно назначение ролей безопасности учетным записям. Слабая аутентификация стала проблемой безопасности с того момента как человек начал использовать этот механизм для защиты своей собственности. Но даже несмотря на то, что уязвимости в механизмах аутентификации существуют достаточно долго, в программе безопасности должны быть предусмотрены меры по устранению этого недостатка. Понимать механизмы аутентификации в SQL Server критически важно при реализации проекта по мониторингу и ведению журналов безопасности. Отслеживание аутентификаций пользователей – основной компонент любой успешной программы по безопасности. В Microsoft SQL Server есть два режима аутентификации: Windows-аутентификация и смешанная аутентификация. Windows-аутентификация при опознавании пользователей опирается на средства ОС Windows и групп пользователей, используя протокол безопасности Kerberos. SQL Server подтверждает учетные записи пользователей, предоставляемые Windows, используя Kerberos; В Windows происходит проверка учетной записи пользователя. SQL Server не производит проверку учетных записей и не спрашивает пароля. SQL-соединения, отнесенные к надежным, - соединения созданные посредством Windows-аутентификации, поскольку SQL Server доверяет учетным записям, предоставленным Windows. Такой метод более безопасен, поскольку используется политика паролей Active Directory, которая согласуется со стандартом корпоративной безопасности. Параметры паролей (сложность, истечение срока действия, блокировка) устанавливаются внутри Active Directory. Пользователям достаточно знать один пароль для доступа и к операционной системе и к SQL Server и не нужно помнить дополнительных паролей или ставить под угрозу безопасность среды при использовании простого пароля. Windows-аутентификация настроена по умолчанию и рекомендована к использованию компанией Microsoft.

Если SQL Server использует смешанную аутентификацию, пользователи могут аутентифицироваться как через Windows, так и через SQL Server. Используя смешанную аутентификацию, вначале SQL Server будет аутентифицировать пользователей через протокол Kerberos. Если аутентификация прошла неудачно, далее SQL Server будет аутентифицировать клиента при помощи имени пользователя и пароля, которые хранятся на SQL Server. Следует отметить, что SQL Server не ограничивает и не переопределяет права локальных администраторов на компьютере, на котором находится SQL Server. У пользователя останутся те права, которые у него есть в операционной системе, находящейся на хосте. Кроме того, не существует способа отключить Windows-аутентификацию (Microsoft, 2012, см. Раздел Ссылки).

Рекомендуется использовать Windows-аутентификацию для авторизации на SQL Server. У этого механизма есть два преимущества. Во-первых, политика корпоративных паролей распространится и на аутентификацию к базе данных, что позволит пользователю не перегружать голову дополнительным запоминанием пароля, поскольку пароль в Active Directory будет действителен и во время аутентификации к базе данных. Если корпоративная политика строгая, то политика паролей к базе данных также будет строгой. Поскольку в базе данных вполне вероятно может находиться конфиденциальная информация, использование устойчивых паролей критически важно для бизнеса. К тому же это может помочь компаниям успешно пройти аудит безопасности.

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

Отчет об аутентификациях к базе данных со слабыми паролями

7.3 SQL-инъекции

Атаки с использованием SQL-инъекций – наиболее распространены и эффективны. Однако разработчики могут защититься от них без серьезных затрат и потерь производительности. Организация OWASP публикует памятку, которую можно рассматривать как руководство по защите от уязвимостей на основе SQL-инъекций. Первая рекомендация – использовать сохраненные процедуры и подготовленные операторы там, где это возможно. Для снижения риска появления уязвимостей следует использовать параметризированный код вместо того, чтобы собирать его на лету. Ниже показан пример сохраненной процедуры, в которой динамический SQL конвертируется в параметризированный SQL.

Код, уязвимый к SQL-инъекции

ALTER PROCEDURE GetCodes
(
@ ProductName[nvarchar](32),
@ProductSkew[nvarchar](32)
)
AS
EXECUTE (`SELECT * FROM Products WHERE ProductName =`”+@ ProductName+`”
AND ProductSkew =`”+@ProductSkew+`”)
RETURN

Параметризированный SQL, защищенный от SQL-инъекции

SELECT * From Products where ProductName = @ ProductName AND ProductSkew =
@ProductSkew

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

Еще одна техника – обработка данных, вводимых пользователем (экранирование, обработка специальных символов и т. д.), перед их использованием в запросе. Эту технику можно использовать в том случае, если существуют проблемы с конвертацией динамических запросов в сохраненные процедуры или подготовленные операторы. Подобная техника весьма рискованна, поскольку ее использование может ухудшить производительность приложений. Используйте этот метод с осторожностью, когда модификация унаследованного кода экономически целесообразна. При реализации приложения с нуля наилучший способ – использовать параметризированные запросы.

Реализация принципа наименьших необходимых привилегий и реализация контроля над доступом к базе на уровне запросов минимизирует ущерб от атак с использованием SQL-инъекций. Учетная запись базы данных, используемая в приложении, не должна быть с административными привилегиями. В противном случае при успешной атаке с использованием SQL-инъекций злоумышленник получит полный контроль над базой и информацией, находящейся в ней. С самого начала определите, какие права необходимы учетным записям, которые используют приложения и службы. Попытайтесь выяснить, какие права доступа действительно нужны, а какие излишни. Избегайте выдачи прав на создание или удаление объектов внутри базы данных. Если учетной записи необходим доступ лишь к части данных, рассмотрите возможность создания представления в базе данных для ограниченного доступа к информации в режиме «только чтение» вместо того, что разрешать доступ ко всей таблице или набору данных. Постарайтесь ограничить доступ у учетных записей, используемых службами, к сохраненным процедурам, а не к самим таблицам. Это будет возможно, если в политике прописано повсеместное использование сохраненных процедур (OWASP, 2012, см. Раздел Ссылки).

SQL Server (или любую другую СУБД) не следует запускать под учетной записью с очень высокими привилегиями (например, под учетной записью system или root). По умолчанию большинство баз данных запускаются под учетной записью с высокими привилегиями. В частности, SQL Server по умолчанию запускается под учетной записью system. Намного безопаснее запускать СУБД, используя учетную запись службы с наименее необходимыми привилегиями. Это поможет минимизировать ущерб от атак с использованием эксплоитов, которые эксплуатируют уязвимость базы данных (Ottman, 2010, см. Раздел Ссылки).

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

При использовании приложений для ведения журнала и мониторинга баз данных довольно просто получить отчет о попытках использования SQL-инъекций, поскольку у всех поставщиков есть разработанные правила, предназначенные для мониторинга SQL-инъекций. Если разработчики придерживаются небрежного стиля кодирования, у правил, направленных на поиск SQL-инъекций, будут ложные срабатывания. К примеру, наиболее распространенное срабатывание происходит, когда ленивый разработчик закомментировал SQL-выражение и оставил его в рабочей среде. Это приведет к срабатыванию правил. Однако если рекомендации даются к месту, нестабильный код все равно не следует оставлять в рабочей среде, чтобы снизить ложные срабатывания (OWASP, 2012).

7.4 Слабый аудит

Слабый аудит может погубить компанию, поскольку в случае взлома невозможно понять, кто получил доступ, и какая информация утекла на сторону. Возможность связать пользователей с выполненными запросами и, соответственно, с данными, к которым был получен доступ, - чрезвычайно важна и может спасти компанию от краха. Определение конфиденциальной и важной информации следует сделать во время процесса проектирования и разработки. Как только конфиденциальная информация опознана, разработчикам следует предпринять особые меры по ведению журнала и мониторингу доступа к этой информации. Группа безопасности может использовать эту информацию для создания специальных правил, которые отслеживают доступ к конфиденциальным данным. Не менее важно уметь преобразовывать собранную информацию в отчеты, понятные для владельцев бизнеса. К примеру, если в отчете указано, что осуществлялся доступ к 27 записям, то такой отчет, по сути, будет бесполезен. Его просто не поймет неподготовленный человек. Совсем другое дело, когда в отчете указано, что осуществлялся доступ к 55 записям, в которых находится информация отдела кадров (Shulman, 2006, см. Раздел Ссылки).

Отчет ниже - пример наглядного отображения результатов мониторинга доступа к корпоративной информации. Отчет показывает, что пользователи осуществляли доступ к информации отдела кадров и SSN-номерам, используя безопасный вход. Также осуществлялся доступ к информации при помощи инструментов Microsoft Office. Использование инструментов Microsoft Office – тревожный сигнал. В компании могут быть пользователи, которые хранят информацию на ноутбуках, общих сетевых ресурсах, мобильных устройствах и т. д. В Приложении А находится пример политики, в которой охватываются вопросы доступа к данным при помощи инструментов Microsoft Office и им подобных. Использование инструментов Microsoft Office для доступа к конфиденциальным данным – нарушение корпоративной политики, которое становится причиной расследования того, почему такое происходит.

Наглядный отчет о результатах мониторинга для владельцев бизнеса

В случае проникновения в систему, возможность выяснить того, кто осуществил доступ и к каким данным, может помочь сэкономить корпорации много денег. На слайде ниже показан сеанс работы пользователя «Jim», который при поиске информации осуществил доступ к базе отдела кадров. На рисунке показана вся информация, необходимая для расследования и выяснения кем, когда и какой информации был осуществлен доступ. Это пример качественного аудита, у которого будет много применений внутри корпорации.

Детальная информация о сеансе работы с SQL Server

7.5 Уязвимости в коммуникационных протоколах базы данных и DOS-атаки

DOS-атаки и атаки на протоколы имеют похожую природу и, следовательно, компенсирующие элементы контроля для них одинаковы. Для защиты от подобных атак требуется тщательный и всесторонний подход, при котором используется сетевой мониторинг, мониторинг времени выполнения запросов и времени отклика и регулирование трафика, если это необходимо. Использование только одного элемента для защиты от DOS-атак и атак на протоколы будет неэффективным, и у злоумышленника будет слишком много возможностей для совершения атаки. Цель DOS-атак – нарушение работы службы, когда потребляется слишком много ресурсов. Целью атак на протоколы базы данных, как правило, является получение несанкционированного доступа, изменение данных или нарушение работы службы (как и в случае с DOS-атаками). Работать с коммуникационными протоколами баз данных весьма непросто, поскольку следы атак на протоколы не отображаются журналах собственного аудита. Аудит базы данных не отслеживает операции, связанные с протоколами. Реализация системы сетевого мониторинга базы данных может помочь в детектирование некоторых, но не всех DOS-атак и атак на коммуникационные протоколы. Детектирование подобных атак возможно именно при сетевом мониторинге, поскольку система сохраняет информацию о времени ответа на запросы и собирает данные о сетевых соединениях. Кроме того, возможность детектировать DOS-атаки и атаки на коммуникационные протоколы – одно из серьезных преимуществ сетевого мониторинга над мониторингом при помощи централизованных агентов. У централизованных агентов будут трудности при детектировании сетевых атак, поскольку в журналах находятся недостаточно детализированные сетевые данные. На рисунке ниже показан пример простейшего мониторинга, используемого для детектирования DOS-атак и атак на коммуникационные протоколы (Shulman, 2006, см. Раздел Ссылки).

Наглядный отчет о медленно выполняемых запросах

Детализация по одному из медленно выполняемых запросов

По результатам отчета могло быть инициировано исследование запроса, который выполнялся в течение 24 часов. Этот запрос мог быть частью обычного бизнес-процесса или результатом работы некачественного кода или запросом, запущенным в злонамеренных целях. Если рассматривать ситуацию с точки зрения бизнеса, возможно, запрос поднимает большое количество данных, за последний месяц, квартал или год. Результатом столь долгого выполнения запроса мог стать некачественный код или неправильно сконфигурированная базы данных. Еще один вариант: возможно, злоумышленник пытается запустить несколько запросов, которые возвращают огромный объем информации, с намерением нарушить работу службы. Сотрудники безопасности, взаимодействующие с владельцами бизнеса, должны определить, запущен ли запрос в злонамеренных целях или является частью нормальных бизнес-процессов. Компаниям следует на регулярной основе отслеживать доступ к конфиденциальной информации, административные действия, использование служебных и привилегированных учетных записей и попытки неправомерного доступа. Эти отчеты помогут удостовериться в том, что действия сотрудников и выполнение процессов согласуется с политикой компании, а также помогут обнаружить потенциально вредоносную деятельность.

Однако глупо ограничиваться только мониторингом базы данных. Это противоречит тщательному и всестороннему подходу к защите рабочей среды. Реализация дополнительных мер по защите базы данных и операционной системы, используя лучшие практические руководства от компаний подобных CIS, также может помочь в предотвращении некоторых видов атак. Кроме того, ревизия и укрепление процедур, ориентированных на работу с сетью также может добавить устойчивости всей системе, в которую злоумышленник пытается проникнуть через разные двери. Однако перед реализацией любой дополнительной защиты следует все проверить и тщательно протестировать, чтобы удостовериться, что новые защитные средства не повлияют на бизнес-процессы. Ранее уже говорилось о мониторинге журналов операционной системы на предмет событий, возникающих в системе безопасности. Регулярное отслеживание подобных событий – прекрасный способ опознать DOS-атаки и атаки на коммуникационные протоколы. Как обсуждалось ранее, реализация контроля над доступом на уровне запросом может помочь в минимизации ущерба от успешно выполненных атак на коммуникационные протоколы. Хотя, подобный контроль может не сильно помочь в случае с DOS-атакой. SQL Server (или любую другую СУБД) не следует запускать под учетной записью с высокими привилегиями (system или root). По умолчанию большинство баз данных запускаются под учетной записью с высокими привилегиями. SQL Server будет запущен под учетной записью system, однако было бы разумнее это сделать под учетной записью с наименьшим необходимым уровнем привилегий (как, впрочем, и любую другую СУБД). Запуск SQL Server с минимально необходимыми привилегиями может помочь в минимизации ущерба от атак, использующих уязвимость в платформе базы данных (Natan, 2005, см. Раздел Ссылки).

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

Хороший способ обнаружить DOS-атаки и атаки на протоколы – просмотр журналов фаервола и IDS/IPS систем (Intrusion Detection System/Intrusion Prevention System, система обнаружения вторжений/система предотвращения вторжений). Сетевые элементы защиты могут отслеживать аномалии в работе протоколов и, потенциально, блокировать вредоносный трафик перед соединением с базой данных. Атаки на протоколы могут быть трудны в обнаружении. При защите корпоративных активов требуется использовать нескольких инструментов. Использование лишь какой-то одной технологии не поможет в надежной защите информации и активов компании.

И, наконец, если в компании налажено управление событиями информационной безопасности (Security Information and Event Management, SIEM), сопоставление данных сети, фаервола, IDS/IPS, операционной системы и базы данных поможет в обнаружении самых изощренных атак. SIEM – дорогостоящая технология. Чтобы получить максимальную выгоду, требуются значительные трудозатраты и ресурсы. Однако эта технология реально может помочь в самых трудных ситуациях.

7.6 Незащищенность резервной копии

Вне зависимости от предпринятых мер безопасности и политик незашифрованная резервная копия, покидающая офис компании, - уязвима. Только представьте: внедрены все самые лучшие меры защиты, а резервная копия попадает в руки злоумышленников во время транспортировки. Стоимость устройства для шифрования резервной копии может быть высокой, и если бюджет невелик, компании должна оценить все риски, связанные с потерей носителя с резервной копией. Внедрение устройства шифрования – нетривиальная задача. Потребуются ресурсы для конфигурирования устройства под рабочую среду. Как только устройство готово к работе, его необходимо подвергать регулярному техническому обслуживанию, установке заплат и ремонту железа, если это необходимо. Наиболее распространенные коммерческие продукты (на момент написания статьи) не имеют встроенных средств шифрования резервных копий. Покупатели же могут надеяться, что в будущем это станет реальностью и заказ дорогостоящего устройства для резервных копий для удовлетворения нормативам и нуждам бизнеса будет доступен при покупке коммерческих продуктов.

Заказ и внедрение устройств шифрования может зависеть от финансовых возможностей компании или требований законов и нормативных правил. Отслеживание лент во время транспортировки – весьма затруднительная задача. Существуют путевые журналы и другие меры по предотвращению хищений, однако, в конечном счете, компания должна доверять перевозчику, выполняющему свою работу (Shulman, 2006, см. Раздел Ссылки).

8. Вывод

Успешная реализация программы по ведению журнала безопасности и мониторингу – больше, чем просто установка и включение «прибора безопасности». Программа – это взаимосвязь людей, процессов и технологий. Ведение журнала безопасности и мониторинг базы данных еще более сложен, поскольку данные, хранящиеся в базе, часто являются конфиденциальными. При реализации мониторинга постоянно следует искать компромисс между риском, выгодой и производительностью. Поскольку мониторинг базы данных включает в себя множество элементов, различные части инфраструктуры – критически важны при реализации успешной программы. При создании стратегии реализации и проверке доступа к информации со стороны привилегированных пользователей затрагиваются несколько областей безопасности баз данных.

Принцип наименьших необходимых привилегий, в случае его грамотной реализации, может помочь в минимизации ущерба от использования уязвимостей. Контроля над доступом на уровне запросов также может помочь минимизировать ущерб после реализации успешных атак. SQL Server (или любую другую СУБД) не следует запускать под учетной записью с высокими привилегиями (например, system или root). По умолчанию большинство баз данных работают под учетными записями с высокими привилегиями. Однако было разумнее запускать SQL Server (или любую другую СУБД) под учетной записью с наименее необходимым уровнем привилегий. Это позволит минимизировать последствия ущерба в случае реализации успешной атаки, эксплуатирующей уязвимость базы данных. Подобные принципы следует применять для любой базы данных, и в случае следования этим правилам уровень безопасности базы существенно возрастет.

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

Ссылки

Encryption Hierarchy. (n.d.). MSDN – Explore Windows, Web, Cloud, and Windows Phone Software Development. Retrieved July 1, 2012, from http://msdn.microsoft.com/en-us/library/ms189586%28v=sql.100%29

Ashford, W. (2012, July 26). SQL injection attacks rise sharply in second quarter of

2012. ComputerWeekly.com | Information Technology (IT) News, UK IT Jobs,

Industry News. Retrieved August 1, 2012, from http://www.computerweekly.com/news/2240160266/SQL-injection-attacks-risesharply-in-second-quarter-of-2012

Auditing Security Events Best practices: Auditing. (2005, January 25). Resources and Tools for IT Professionals | TechNet. Retrieved July 15, 2012, from http://technet.microsoft.com/en-us/library/cc778162%28v=ws.10%29.aspx

Auditing Security Events Best practices: Auditing. (2005, January 25). Resources and Tools for IT Professionals | TechNet. Retrieved July 15, 2012, from http://technet.microsoft.com/en-us/library/cc778162%28v=ws.10%29.aspx

B, D. (2012, March 14). â€oeThe SQL Guy†Post #20: Using Cell Level Encryption in SQL Server - Canadian IT Professionals - Site Home – TechNet Blogs. TechNet Blogs - TechNet Blogs. Retrieved July 1, 2012, from http://blogs.technet.com/b/canitpro/archive/2012/03/14/the-sql-guy-post-20-using-cell-level-encryption-in-sql-server.aspx

Chapman, T. (n.d.). Center for Internet Security :: Security Benchmarks Division :: CIS SQL Server 2005 Benchmark v2.0.0. Center for Internet Security :: Security Benchmarks Division :: Home. Retrieved June 27, 2012, from http://benchmarks.cisecurity.org/enus/?route=downloads.show.single.sql2005.200

Choose an Authentication Mode. (n.d.). MSDN. Retrieved May 20, 2012, from msdn.microsoft.com/en-us/library/ms144284.aspx

Clarke, J. (2009). SQL injection attacks and defense. Burlington, MA: Syngress Pub..

Cristofor, L. (2007, October 3). SQL Server 2008: Transparent data encryption feature - a quick overview - Laurentiu Cristofor's blog @microsoft.com – Site Home - MSDN Blogs. MSDN Blogs - MSDN Blogs. Retrieved July 2, 2012, from http://blogs.msdn.com/b/lcris/archive/2007/10/03/sql-server-2008-transparent-data-encryption-feature-a-quick-overview.aspx

Kerberos Explained. (n.d.). Resources and Tools for IT Professionals | TechNet. Retrieved July 15, 2012, from http://technet.microsoft.com/enus/library/bb742516.aspx

Kiely, D. (n.d.). Protect Sensitive Data Using Encryption in SQL Server 2005. SQL Encryption - Microsoft. Retrieved June 22, 2012, from download.microsoft.com/download/4/7/a/.../SQLEncryption.doc

McKendrick, J. (n.d.). Cost of a data breach: $194 per record | SmartPlanet. SmartPlanet- Innovative Ideas That Impact Your World. Retrieved June 8, 2012, from

http://www.smartplanet.com/blog/business-brains/cost-of-a-data-breach-194-perrecord/22913

McKendrick, J. (n.d.). Cost of a data breach: $194 per record | SmartPlanet. SmartPlanet

- Innovative Ideas That Impact Your World. Retrieved June 8, 2012, from http://www.smartplanet.com/blog/business-brains/cost-of-a-data-breach-194-per-record/22913

Northcutt, S. (2010). Management 404 - Fundamentals of Information Security Policy. Bethesda, Maryland: The SANS Institute.

SQL Injection Prevention Cheat Sheet. (2012, July 9). OWASP The Open Web Application Security Project. Retrieved September 1, 2012, from https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

SQL Injecttion. (2012, July 8). OWASP The Open Web Application Security Project. Retrieved September 1, 2012, fromhttps://www.owasp.org/index.php/SQL_Injection success, a., & category, f. e. (n.d.).

Auditing Security Events Best practices: Auditing. Resources and Tools for IT Professionals | TechNet. Retrieved July 15, 2012, from http://technet.microsoft.com/en-us/library/cc778162%28v=ws.10%29.aspx

Приложение А

Требования к ведению журнала и мониторингу базы данных от 20 мая 2012 года

Компания Х

Адрес

Город, Штат XXXX-XXXX

Корпоративная безопасность Компании Х

Политика: Ведение журнала и мониторинг базы данных

Требования к ведению журнала и мониторингу базы данных

Аудитоспособность относится к функциям приложения, при помощи которых осуществляется отслеживание активности. Аудит должен предоставлять достоверную информацию для расследования случаев несанкционированных действий, из-за которых возник инцидент в системе безопасности. Полученная информация позволит персоналу предпринять необходимые мероприятия по ликвидации инцидента. На данный момент в компании Х имеются общие стандарты и руководства для аудитоспособности приложения. Эти стандарты и руководства, относятся к ведению журналов, и их следует рассматривать как справочник для базовых требований по ведению журнала для баз данных. Более подробную информацию можно узнать в разделе 3.4 «Ведение журнала» в корпоративной политике компании.

Поскольку в системах управления базами данных (СУБД) вполне вероятно могут храниться конфиденциальные данных, в этом руководстве изложены дополнительные требования по ведению журнала для того, чтобы аудит и мониторинг выполнялся на должном уровне. Главная цель – сделать так, чтобы эти правила были применены ко всем СУБД вне зависимости от выполняемых ими бизнес-задач и вообще ко всем системам, где хранятся «конфиденциальные» и «регламентированные» данные. На внедрение указанных руководств потребуется определенное время. Перед передачей на сторону любых функций по администрированию баз данных, следует внедрить следующие функциональные элементы контроля по ведению журнала и мониторингу событий.

Ведение журнала базы данных должно осуществляться по следующим видам деятельности:

• Добавление, изменение, приостановка действия и удаление учетных записей пользователей
• Изменение прав у учетных записей пользователей (права доступа учетной записи)
• Повышение привилегий
• Изменения владельца объектов
• Начало/окончание сеанса, неудачные попытки авторизации под учетными записями администратора (учетными записями администраторов баз данных), учетными записями приложений и учетными записями, используемыми для прямого доступа к базе
• Изменение паролей
• Изменение политики безопасности базы данных / изменение настроек
• i. Режимы аутентификации
• ii. Управление паролями
• iii. Запрет/разрешение удаленного доступа
• iv. Запрет/разрешение собственного аудита
• Изменение настоек системы аудита и попытки изменения или удаления логов аудита или логов баз данных
• Транзакции, связанные с конфиденциальными данными, на основе требований владельца данных
• Санкционированный доступ к конфиденциальным ресурсам, на основе требований владельца ресурсов
• Неудачные попытки доступа к конфиденциальным ресурсам, на основе требований владельца ресурсов
• Неудачное выполнение SQL-запросов (из-за отсутствия объекта или недостаточности привилегий)
• Внесение изменений в схему базы данных (Команды DDL (Data Definition Language, язык описания данных))
• Создание/восстановление резервных копий
• Запуск/остановка базы данных
• Попытки использования средств операционной системе через базу данных (выполнение команд, чтение/изменение файлов и настроек)
• В журнале должно быть достаточно информации для того, чтобы была возможность выяснить, какие произошли события, и кто был их инициатором:
• i. Тип события
• ii. Когда произошло событие
• iii. Учетная запись, связанная с событием
• iv. Программа или команда, ставшая инициатором события (точное SQL-выражение)
• v. Имена таблиц, к которым осуществлялся доступ (если возможно)
• vi. Имя хоста или IP-адрес, с которого произошло соединение пользователя
• vii. Статус попытки (успех/неудача)

Команды, зависимые от платформы:

• ORACLE: команды прослушивателя журнала (log listener): SERVICE, STATUS, VERSION, STOP
• MS SQL: команды DBCC

Мониторинг должен сработать при наступлении следующих событий:

• Несогласованные добавления и изменения учетных записей пользователей
• Случаи многократных неудачных попыток ввода паролей по множеству учетных записей за короткий промежуток времени (что может свидетельствовать о реализации хакерских намерений)
• Случаи попыток неудачного доступа к базе данных от имени учетной записи, у которой нет прав доступа
• Попытки получить список пользователей и паролей
• Все попытки прямого доступа к базе данных от имени учетных записей, доступ которым разрешен только из приложения
• Использование нестандартных утилит (например, Excel, Access) для прямого доступа к СУБД
• Использование «служебных программ» (например, Toad) для прямого доступа к СУБД
• Использование Application ID (ApplID) из источника отличного от того, который закреплен за владельцем приложения (на основе имени хоста или IP-адреса)
• Неудачные входы в систему, попытки остановить ведение журнала и уничтожить логи
• Попытки доступа к средствам ОС через базу данных
• Обнаружение известных видов атак (например, переполнение буфера, отказ в обслуживании, SQL-инъекция)

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