Любая система безопасности базируется на вводе тех или иных ограничений
В итоге это все равно приведет к проявлению некоторого дискомфорта в работе обычных пользователей (администраторов). Чем выше уровень безопасности, тем больше ограничений – тем больше неудобств. Не существует вариантов, когда при вводе в эксплуатацию соответствующих систем не пришлось бы чемто жертвовать. Пример: для доступа к ИТинфраструктуре под управлением Active Directory была организована двухфакторная аутентификация [1]. Теперь пользователи вынуждены, помимо запоминания «волшебного слова» (в данном случае PINкода), еще и носить с собой смарткарту. Соответственно рассеянные люди, забывающие карту дома, в сеть попасть не могут, что является весьма раздражающим неудобством. Соответственно при достаточно обширном сочетании подобных ограничений можно добиться значительного замедления в функционировании бизнеспроцессов и даже полной их остановки.n
Усложнение любой системы повышает риск ее выхода из строя
Более сложные системы состоят из большего количества элементов, что, в свою очередь, повышает вероятность выхода из строя.nnНапример, используется смешанная топология резервного копирования, при которой сервер СУБД выгружает рабочие базы данных в специальные файлы, защищенные паролем, а те, в свою очередь, забираются и записываются на ленты системой резервного копирования в зашифрованном виде со специальным криптоключом. Любой мелкий аппаратный сбой (например, некритичный перегрев процессора) во время одной из этих операций может вызвать ошибки при шифровании, что, в свою очередь, превратит резервную копию в нечитаемую. При этом в журналах как сервера БД, так и в системе резервного копирования подобные сбои могут не отражаться.n
Правило «ста долларов»: первые 90% безопасности стоят $10, остальные 10% – оставшиеся $90
Другая опасность заключается в том, что можно просто утратить один из ключей и получить бесполезный набор нулей и единиц вместо актуальной резервной копии. Особенно такие проблемы характерны для архивного копирования, когда копии могут храниться по нескольку лет без попытки использования.nnСтановится очевидно, что уровень системы безопасности должен соответствовать требуемому значению. Если принятые меры не защищают от возможных угроз, с большой вероятностью данные будут подвержены утечке. Если степень защиты превосходит уровень угроз, то возрастают риски, связанные с повышением стоимости обслуживания и вероятностью сбоев самой системы защиты данных. Существует простое правило «ста долларов» при обеспечении безопасности: первые 90% безопасности стоят 10 долларов, остальные 10% – оставшиеся 90 долларов.nnРоли при выполнении резервного копированияnnДля упрощения разграничений прав доступа в современных системах резервного копирования (и не только) используют ролевую модель. Проще говоря, все права и доступные функции группируются в некоторый заранее определенный набор – «роль», которая соотносится с тем или иным пользователем или группой.nnОбычно выделяют две роли: «администратор системы резервного копирования» и «оператор резервного копирования». Различаются они в первую очередь возможностью управления самой backupсистемой. Например, администратор может создавать политики с заданиями на резервное копирование, а оператор сам создавать не может, но может изменять расписание запуска, наблюдать за ходом их выполнения, при необходимости останавливать и запускать заново.nnЭто делается для сохранности самой системы резервного копирования при делегировании полномочий третьим лицам. Например, при организации защиты филиальной структуры местные сотрудники сами заменяют носители для резервных копий, но они не смогут внести искажения в политики резервного копирования. Происходит своего рода страховка от неквалифицированного вмешательства или заведомого вредительства.nnПримечание.>В некоторых случаях вводится еще третья главенствующая роль – «архитектор системы резервного копирования». Чаще всего это сотрудник, в чьи обязанности входит решение глобальных вопросов, связанных с backupсиcтемой, например, работа с базой данных, где хранится информация о резервных копиях, решение задач, связанных с криптозащитой носителей (об этом мы поговорим ниже), и так далее. Обычных рутинных задач, связанных с регулярным резервным копированием вроде запускаостановки политик и учета резервных копий, он не касается. Введение такой дополнительной «надстройки» оправдано в крупных компаниях с распределенной многоуровневой системой резервного копирования.nnНа практике трехзвенное разграничение прав встречается крайне редко. Но почти всегда присутствует две роли, о которых шла речь выше: администратор и оператор.nnЕсли ИТслужбе предъявляются высокие требования к минимизации простоев и/или сохранности данных, существует практика использования двух независимых систем резервного копирования. Например, одна система использует блочный бэкап и применяется при снятии образов системы для Disaster Recovery, а вторая использует файловый доступ и применяется для организации архивного хранения. Этот довольно популярный способ разделения функций таит в себе дополнительную угрозу безопасности. Необходимо, чтобы за обе системы отвечала одна и та же группа лиц, а полномочия по снятию информации не размазывались тонким слоем по всему коллективу айтишников.n
Классификация и структура методов обеспечения безопасности при резервном копировании
Существует довольно много методов, которые используются для защиты информации от несанкционированного доступа через резервное копирование. Чтобы не допускать излишней избыточности и в то же время не оставить брешь в защите, необходимо использовать некоторую классификацию. Все используемые методы можно разделить на два основных направления:n
- Ограничение возможности копирования данных.
- Ограничение возможности использования резервных копий.
Ограничение возможности копирования данных
Наиболее идеальная утечка данных в этом случае – сделать свою собственную резервную копию на удаленный ресурс или на собственный локальный носитель, чтобы потом тихо вынести его за пределы периметра. Поэтому так важно защитить свою систему от взлома еще на этапе копирования.nnПринимаемые меры безопасности можно разделить на два направления:n
- Доступ к системе резервного копирования.
- Доступ к ресурсам, которые могут быть скопированы.
Ограничение доступа к системе резервного копирования
Данный вопрос разделяется на две независимые задачи: защита на уровне приложения, т.е. самой системы резервного копирования, и защита на более «низком уровне» – например, ограничение доступа к серверу резервного копирования, отсутствие возможности запуска резервного копирования сетевых ресурсов от недопустимой учетной записи.nnПрекрасным примером для данного случая может послужить защита паролем управляющей консоли системы резервного копирования. Когда нет возможности напрямую подглядеть в консоли, что и куда копируется и когда будет готова очередная копия, получить информацию о месте размещения только что созданной резервной копии, а также о ее содержимом становится весьма непростым делом для посторонних людей.nnПомимо пароля на консоль программы, стоит позаботиться об ограничении доступа к самому серверу резервного копирования. Желательно, чтобы к нему невозможно было подключиться не только рядовым пользователям, но и другим ИТспециалистам компании, не обладающим полномочиями администратора резервного копирования.nnЧто касается роли оператора, то будет весьма неплохо, если он сможет запускать консоль управления со своего рабочего компьютера, не подключаясь к серверу средствами удаленного управления: RDP, VNC, SSH, Telnet и так далее.nnИ, разумеется, не стоит открывать общие ресурсы на любом сервере, предназначенном для системы резервного копирования, будь то управляющие или медиасервер. Исключение составляет децентрализованная топология, когда на каждом сервере сети размещается отдельная копия ПО, которая записывает резервные копии на серверхранилище. Даже здесь можно ввести необходимые ограничения, например, «урезав» права учетной записи оператора, чтобы разрешить только управление консолью управления backupсистемы.nnОграничение доступа к ресурсам, которые могут быть скопированыnnВ любой ситуации всегда есть обходные пути. Например, чтобы получить доступ к данным, необязательно использовать консоль централизованной системы резервного копирования. О методах закрытия таких путей и пойдет речь ниже Контроль за ресурсами можно разделить на два направления:n
- ограничение доступности через учетную запись;
- ограничения доступа общего характера.
Ограничение> доступа> через> учетную> запись. Несмотря на то что этот пункт в построении системы кажется очевидным и понятным, все равно его лучше проиллюстрировать на примере.nnДопустим, система резервного копирования использует служебную учетную запись пользователя backupадмин для доступа к тем или иным ресурсам. Получив пароль этой записи, можно попытаться подключиться напрямую к требуемым ресурсам. Если речь идет о платформе Windows, то можно попробовать открыть себе доступ по протоколам CIFS/SMB, использовать соединение RPC, чтобы разрешить себе доступ через средства управления ОС. В волшебном мире UNIX для этих целей подходит вездесущий SSH с его возможностью не только управлять системой, но и копировать файлы по протоколам SCP/SFTP.nnЕще одна возможность для злоумышленника – постараться перенести нужную информацию с защищенного на публично доступный ресурс. Например, скопировать файлы с закрытого каталога в папку Public, к которой имеют доступ все пользователи. Или сделать дамп базы данных MySQL в папку tmp с последующим копированием в нужное место.nnРазумеется, подобные «лазейки» должны быть закрыты, а реквизиты для доступа должны храниться в строгом секрете. И чего уж точно не надо делать, так это использовать учетную запись системы резервного копирования для вспомогательных целей, например, для рассылки сообщений системой мониторинга, подключения систем диагностики и так далее. У каждой службы должен быть свой собственный аккаунт с узкими специальными полномочиями.nnОсобое внимание к безопасности необходимо во время так называемых переходных периодов, когда ИТинфраструктура модернизирует систему резервного копирования или меняет ее на более удовлетворяющую. Чтобы абстрагироваться от ошибок изза нехватки прав доступаnnпри тестировании новой системы учетной записи предоставляют максимальные права. Впоследствии, когда новая backupсистема внедрена и отлажена, о расширенных правах забывают и все остается работать до первого серьезного инцидента. Учитывая уровень доступа, который может получить злоумышленник, этот инцидент способен стать критическим для жизнедеятельности организации.nnИногда во время таких переходов работают разу две системы резервного копирования: старая и вновь внедряемая. Новая система успешно проходит испытания, а устаревшая… так и продолжает работать. Если данных немного, все процессы и есть возможность складывать копии без переполнения ресурсов (например, на дисковое хранилище с хорошо настроенной системой ротации), то такой «бэкдор» может работать довольно долго, радуя своим существованием охотников за чужими данными.n
Кассеты с записью бизнесинформации – это не золотые слитки, но порой стоимость их содержимого может составлять целое состояние
Ограничение> доступа> общего> характера. В данном разделе речь пойдет о дополнительных мерах, способных усложнить жизнь злоумышленника. К сожалению, в рамках небольшой статьи нельзя затронуть все аспекты обеспечения безопасности, поэтому мы подробно рассмотрим несколько ключевых моментов. О защите ИТсистем прекрасно написано в книге Андрея Бирюкова , в которой автор не только приводит подробную информацию о системах безопасности, но и рассматриваются интересные нюансы.nnДля подобных мер защиты хорошо подходит система разграничений на уровне сети. Если пользовательская сеть разделена на несколько виртуальных сетей (VLAN), это позволяет ограничить доступ пользователей к тем или иным объектам. Разделение сети на подсеть для рабочих станций и серверную значительно осложняет несанкционированный доступ к данным. Дальнейшее дробление еще больше повышает уровень безопасности. Например, можно запретить доступ к серверам БД с рабочих станций сотрудников, в служебные обязанности которых не входит работа с подобной информацией. Сотрудникам отдела рекламы совсем не обязательно иметь возможность подключаться к серверу СУБД для бухгалтерии, так же как и бухгалтерам не нужно иметь возможность просматривать свежие эскизы рекламных проектов. Если у каждой группы пользователей есть сегмент, куда они должны получить доступ по служебной необходимости, а вся остальная ИТинфраструктура закрыта для проникновения, это можно считать хорошим достижением.nnРазделение по протоколам также дает хороший результат. Простое использование файрвола значительно снижает вероятность несанкционированного доступа. Большинство систем резервного копирования использует свой собственный протокол для обмена инструкциями и получения данных от своих программагентов. Можно просто закрыть соответствующие TCPпорты, оставив доступ только для серверов резервного копирования.nnРазумеется, использовать централизованную систему управления сетевым доступом предпочтительнее, нежели каждый раз настраивать файрвол на отдельном сервере. Такое управление возможно, например, при использовании сетевых коммутаторов третьего уровня с поддержкой accesslists – ACL .nnНо не стоит забывать о том, что все хорошо в меру. При любых обстоятельствах уровень защиты должен соответствовать уровню угроз, но не более того.nnОграничения возможности использования резервных копийnnДанное направление делится на два основных направления:n
- Ограничение физического доступа к резервным копиям, хранение в надежном месте, опечатывание.
- Ограничение возможности применения резервных копий: шифрование, маркировка, сокрытие процедур создания резервных копий (структура данных, график, схема ротаций).
Не будем забегать вперед и рассмотрим все по порядку.n
Ограничение физического доступ к резервным копиям
На первый взгляд это самый бесхитростный пункт в обеспечении системы безопасности резервного копирования. Здравый смысл подсказывает, что ценные предметы нужно хранить в запертом сейфе или несгораемом шкафу в охраняемом помещении с надежной дверью и решетками на окнах. Также не помешает сигнализация и система видеонаблюдения.nnРазумеется, кассеты с записью бизнесинформации – это не золотые слитки, но порой стоимость их содержимого может составлять целое состояние. В то же время нет смысла держать резервные копии «за семью печатями», так как данные могут понадобиться в любой момент. То, что я писал выше по поводу избыточности средств защиты, как нельзя лучше применимо к ограничению физического доступа. Нет смысла покупать дорогостоящий сейф там, где можно обойтись несгораемым шкафом. Не стоит покупать сверхсекретный биометрический замок там, где достаточно обычных ключей. Затраты на хранение накопителей диктуют здравый смысл и финансовые возможности.nnНо что делать, когда резервное копирование производится на дисковое хранилище? При таком способе хранения резервных копий возникает масса трудностей с обеспечением безопасности. Невозможно каждый раз после создания копии демонтировать хранилище и прятать в сейф. В этом случае в качестве ограничительной меры подойдет надежный серверный шкаф с запирающейся дверью. Желательно вынести дисковую систему хранения бэкапов в отдельное помещение или разместить за изолирующей перегородкой.nnНо основной способ получения данных с дискового хранилища – через сеть, поэтому нужно обеспечить ограничение доступа по сети. Хорошая идея: защитить общие ресурсы сложным паролем, разместить хранилище за файрволом и настроить список доступа на сетевом оборудовании. Сочетание перечисленных мер дает хороший эффект и предотвращает большинство вторжений nnСуществуют и другие меры ограничения доступа. Например, использование топологии LANFree в сети передачи данных (SAN) на базе оптоволоконных соединений значительно безопаснее, нежели использование обычной локальной сети.nn nnРазумеется, ничего не дается бесплатно. Применение файрвола снижает производительность локальной сети, а топология LANFree, помимо покупки соответствующего ПО, потребует организации самой SAN. Но все же следует понимать важность принимаемых мер и не пытаться выдать за экономию жадность и безответственность.nn nnОграничения возможности применения резервных копийnn nnПараллельно с ограничением доступа к резервным копиям необходимо предусмотреть меры по защите от использования посторонними лицами. Проще говоря, даже если злоумышленник сможет получить себе экземпляр копии данных, он не должен знать, как это использовать.nnТакую защиту предоставляет шифрование данных. Большинство систем резервного копирования имеет свою встроенную криптографическую систему, основанную на известных алгоритмах. Такие резервные копии, создаваемые как на съемных носителях, так и на дисковых подсистемах, прочитать без ключа будет непросто.nnАппаратная поддержка систем шифрования облегчает процедуру создания резервных копий без потери производительности. Например, оборудование, поддерживающее стандарт LTO, начиная с версии LTO4 предоставляет возможность использовать собственный чип, встраиваемый в ленточный картридж и упрощающий процедуру кодирования данных. Обратной стороной шифрования является невозможность сжатия данных.nnДля защиты бэкапов, размещенных на дисковых подсистемах, можно порекомендовать, помимо использования встроенных возможностей ПО резервного копирования, применять VPNсоединение и шифрование дисковых разделов. Это дает дополнительную защиту от атак вроде Man in the Middle («человек в середине»), когда посторонний участник процесса подключается к каналу, подменяя ключи шифрования. Но, помимо шифрования, существует немало других способов усложнить жизнь злоумышленников. Хорошую службу может сослужить особая маркировка копий, непонятная для злоумышленника. Например, ленточные носители подписываются не как «База бухгалтерии за июнь», а «Копия 6 источника 1». В идеале для маркировки можно использовать абсолютно нейтральные значения, например, серийный номер носителя. В этом случае гораздо сложнее определить, что это за копия и какие данные можно восстановить с ее помощью. Особенно это полезно, когда злоумышленники охотятся за чемто конкретным, например, за данными о контрагентах. В этом случае становится непонятно, какой съемный носитель следует похитить или какой архивный файл переписать с дискового хранилища.nnДопустим, наш злоумышленник разобрался в маркировке, сумел похитить локальный носитель или переписать архивный файл с хранилища, получил ключ с помощью социальной инженерии или взломал с помощью специального оборудования и ПО. Далее, чтобы получить данные, ему необходимо воссоздать некую модель, пусть даже уменьшенную, той инфраструктуры, на которой были созданы эти данные. Допустим, данная операция затевалась в целях получения списка клиентов компании. В руках недоброжелателей оказалась база данных. Значит, необходимо воссоздать аналогичную систему, чтобы просмотреть требуемую информацию. Для этого как минимум потребуется знание, на каком ПО резервного копирования была создана данная копия (таких backupсистем сейчас довольно много) и какое приложение использовалось для работы с даннымиn
Чем меньше злоумышленник знает о восстанавливаемой системе, тем больше трудностей ему предстоит преодолеть
Также может понадобиться знание паролей администратора СУБД для подключения базы. Чем меньше злоумышленник знает о восстанавливаемой системе, тем большие трудности ему предстоит преодолеть. Соответственно вся информация о том, какое программное обеспечение используется, в каких форматах хранятся данные, какова процедура восстановления, представляет такую же тайну, как ключ шифрования или пароль администратора. Чем меньше данных мы сообщаем «наружу», тем более защищенной является система.nnВ данной статье мы разобрали самые простые и наиболее популярные способы обеспечения безопасности при резервном копировании. Разумеется, невозможно в рамках одной публикации описать все многообразие методов, используемых для защиты и нападения. Но, используя предложенный материал, а также здравый смысл, смекалку и элементарные правила осторожности, читатель сможет разработать свою методику обеспечения безопасностиnnИсточник: Системный Администратор №152153nnУслуги настройки систем резервного копирования и обеспечение безопасности, подробнее [email protected]