Администратор windows: кто это, обязанности, зарплаты и как им стать в 2021 году. обзор профессии

Проверки резервных копий

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

Важно понимать, что проверка резервной копии не является проверкой структуры данных в данной резервной копии. Однако если резервная копия была создана с использованием предложения WITH CHECKSUMS, проверка резервной копии с использованием предложения WITH CHECKSUMS может также дать полное представление о надежности данных в данной резервной копии

Sypex Dumper

Лицензия: BSD

Поддерживаемые СУБД: MySQL

Вместе с MySQL поставляются утилиты mysqldump, mysqlhotcopy, позволяющие легко создать дамп базы данных, они хорошо документированы, и в интернете можно найти большое количество готовых примеров и фронтендов. Последние позволяют новичку быстро приступить к работе. Sypex Dumper представляет собой PHP-скрипт, позволяющий легко создать и восстановить копию базы данных MySQL. Создавался для работы с большими базами данных, работает очень быстро, понятен и удобен в использовании. Умеет работать с объектами MySQL — представлениями, процедурами, функциями, триггерами и событиями.

Еще один плюс, в отличие от других инструментов, при экспорте производящих перекодирование в UTF-8, — в Dumper экспорт производится в родной кодировке. Результирующий файл занимает меньше места, а сам процесс происходит быстрее. В одном дампе могут быть объекты с разными кодировками. Причем легко импорт/экспорт произвести в несколько этапов, останавливая процесс во время нагрузки. При возобновлении процедура начнется с места остановки. При восстановлении поддерживается четыре варианта:

• CREATE + INSERT — стандартный режим восстановления;
• TRUNCATE + INSERT — меньше времени на создание таблиц;
• REPLACE — восстанавливаем в рабочей базе старые данные, не затирая новые;
• INSERT IGNORE — добавляем в базу удаленные или новые данные, не трогая существующие.

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

Интерфейс Dumper

Управление производится при помощи веб-браузера, интерфейс с использование AJAX локализован из коробки и создает впечатление работы с настольным приложением. Также возможно запускать задания из консоли и по расписанию (через cron).

Для работы Dumper понадобится классический L|WAMP-сервер, установка обычная для всех приложений, написанных на PHP (копируем файлы и устанавливаем права), и не будет сложной даже для новичка. Проект предоставляет подробную документацию и видеоуроки, демонстрирующие работу с Sypex Dumper.

Есть две редакции: Sypex Dumper (бесплатно) и Pro (10 долларов). Вторая имеет больше возможностей, все отличия приведены на сайте.

4.1 Атаки, проводимые онлайн

Password Guessing или Hammering – это систематический подбор пароля злоумышленником к одной целевой учетной записи. Перебор проводится преимущественно по словарям и по утечкам, найденным в Интернете.

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

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

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

Операции, поддерживаемые журналом транзакций

Журнал транзакций поддерживает следующие операции:

• восстановление отдельных транзакций;
• Восстановление всех незавершенных транзакций при запуске SQL Server.
• накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;
• поддержка репликации транзакций;
• Поддержка решений высокого уровня доступности и аварийного восстановления: Always On группы доступности, зеркальное отображение баз данных и доставка журналов.

Восстановление отдельных транзакций

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

Восстановление всех незавершенных транзакций при запуске SQL Server

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

Накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя

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

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

Поддержка репликации транзакций

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

Поддержка решений высокого уровня доступности и аварийного восстановления

Решения резервного сервера, Always On группы доступности, зеркальное отображение базы данных и доставка журналов, сильно зависят от журнала транзакций.

В сценарии Always On группы доступности каждое обновление базы данных, первичная реплика, немедленно воспроизводится в отдельных полных копиях базы данных, вторичных реплик. Первичная реплика немедленно отсылает каждую запись журнала во вторичные реплики, которые применяют входящие записи к базам данных групп доступности, производя непрерывный накат. Дополнительные сведения см. в разделе Экземпляры отказоустойчивого кластера AlwaysOn.

В сценарии доставки журналов сервер-источник отправляет резервные копии журналов транзакций базы данных-источника в одно или несколько назначений. Каждый сервер-получатель восстанавливает резервные копии журналов в локальную базу данных-получатель. Дополнительные сведения см. в разделе Сведения о доставке журналов.

В сценарии зеркального отражения базы данных каждое изменение в базе данных (основной базе данных) немедленно воспроизводится в ее полной автономной копии (зеркальной базе данных). Экземпляр основного сервера немедленно отсылает каждую запись журнала в экземпляр зеркального сервера, который применяет входящие записи к зеркальной базе данных, путем ее непрерывного наката. Дополнительные сведения см. в разделе Зеркальное отображение базы данных.

Логическая архитектура журнала транзакций

Логически журнал транзакций SQL Server работает так, как если бы он являлся последовательностью записей в журнале. Каждая запись журнала определяется порядковый номер журнала (LSN). Каждая новая запись добавляется в логический конец журнала с номером LSN, который больше номера LSN предыдущей записи. Записи журнала сохраняются в серийной последовательности по мере их создания, таким образом если LSN2 больше, чем LSN1, то изменение, описанное записью журнала, на которую ссылается LSN2, произошло после изменения, описанного записью журнала LSN1. Каждая запись журнала содержит идентификатор транзакции, к которой она относится. Все записи журнала, связанные с определенной транзакцией, с помощью обратных указателей связаны в цепочку, которая предназначена для ускорения отката транзакции.

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

Действия, которые необходимо выполнить для восстановления операции, зависят от типа журнальной записи:

• Зарегистрирована логическая операция.

  • Для наката логической операции выполняется снова.
  • Для отката логической операции выполняется обратная логическая операция.

• Зарегистрированы исходный и результирующий образы записи.

  • Для наката операции применяется изображение после.
  • Для отката операции применяется образ до.

В журнал транзакций записываются различные типы операций, например:

• начало и конец каждой транзакции;

• любые изменения данных (вставка, обновление или удаление), включая изменения в любой таблице (в том числе и в системных таблицах), производимые системными хранимыми процедурами или инструкциями языка DDL;

• любое выделение и освобождение страниц и экстентов;

• создание и удаление таблиц и индексов.

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

Раздел файла журнала из первой записи, который должен присутствовать для успешного отката всей базы данных к последней зарегистрированной записи называется активной частью журнала, активным журналом или заключительным фрагментом журнала. Этот раздел журнала необходим для полного базы данных. Ни одна часть активного журнала не может быть усечена. Порядковый номер журнала (LSN) этой первой записи журнала называется минимальным номером LSN восстановления (MinLSN). Дополнительные сведения об операциях, поддерживаемых журналом транзакций, см. в разделе Журнал транзакций (SQL Server).

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

Отслеживание действий в аккаунтах администраторов

4.2 Атаки, проводимые офлайн

Это единственный вариант, когда сложность пароля по-настоящему имеет значение. При такой атаке злоумышленник уже завладел базой данных учетных записей/паролей целевой компании, в которой пароли хранятся в хэшированном виде (вместо обычных текстовых паролей, что было бы слишком просто). В дальнейшем злоумышленник восстанавливает настоящие пароли из найденных хэш-сумм методом перебора с применением одного из множества свободно распространяемых инструментов (например, John the Ripper или L0phtCrack) или специальной программой, разработанной для этого самим злоумышленником.

Мы не будем подробно описывать принцип работы этих программ (существует множество открытых источников по взлому паролей), но в общем случае злоумышленник может сделать следующее:

1. Создать «брут-машину»: стандартное компьютерное оборудование с высокопроизводительной видеокартой, которое может вычислять и проверять несколько миллиардов несложных хэшей (MD5, SHA1, NTLM и т.д.) в секунду. Легкодоступные установки для добычи криптовалют (майнеры) могут без труда достичь скорости перебора в 100 миллиардов хэшей в секунду, а хорошо финансируемые злоумышленники (прогосударственные группировки) могут достичь скорости и в 100-1000 раз выше.

2. Перебрать все возможные пароли. При использовании майнера и предположении, что мощность словаря пароля составляет 96 символов, бездумное перебирание всех вариантов пароля займёт следующее время:

3. Ускорить перебор, используя дополнительные техники и знания:

   • изучив целевую организацию, злоумышленник может выяснить алгоритм хэширования и специфичные для неё правила генерации паролей (минимальная/максимальная длина, сложность и т. д.);

   • использовать списки паролей, полученные в результате предыдущих взломов (огромное количество паролей уже находятся в свободном доступе). После хеширования проводится проверка на совпадение с хэшами в целевой базе данных. По статистике, это позволяет взломать около 70% паролей пользователей;

     

     

     

     

     

     

     

     

     

     

   • если это не сработает, злоумышленник может составить список всех популярных фраз, текстов песен, заголовков новостей, частых запросов поисковых систем, википедии, популярных статей и т.д. Или взять готовый — подобные списки доступны в различных сообществах «хэшбрейкеров». Таким образом можно подобрать еще 5-7% паролей пользователей;

   • наконец, злоумышленник может использовать предугаданные шаблоны (например, пароль всегда начинается с заглавной буквы, затем 3-6 строчных букв, 2-4 цифры и восклицательный знак в конце) и подобрать более длинные пароли (до 12 символов). Это позволяет вскрыть еще 5-7% пользовательских паролей.

   4.  В случае использования «соли» для хранения паролей в базе (применения к хэшу дополнительного преобразования, усложняющего автоматический перебор), данные техники применяются не для всех хэшей, а для одного. Вместе с тем, атака проводится с высокой вероятностью успеха почти в 85% и за относительно короткий промежуток времени, что позволяет злоумышленнику перейти к следующей учетной записи и последовательно перебрать их все.

   Здесь стоит отметить следующее:

   • данный метод перебора работает только в том случае, когда у атакующего есть база учетных записей/паролей. Как злоумышленник получил ее? Если уровень доступа атакующего достаточен, чтобы получить базу данных, то целью он, скорее всего, уже владеет;

   • если база данных учетных записей/паролей, полученная злоумышленником, не относится к цели, то взломанный пароль все равно нужно попробовать на реальной учетной записи в целевой системе;

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

   • технические возможности для взлома хэшей постоянно растут. Неужели мы будем постоянно гнаться за ними, делая пароли всё длиннее, сложнее и труднее для запоминания, пытаясь справиться с одним-единственным сценарием атаки? Очевидно, будет лучше использовать более комплексный подход.

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

   Перевод: Аделина Любимова, Origin Security

Handy Backup

Лицензия:коммерческая

Поддерживаемые СУБД:Oracle, MySQL, IBM DB2 (7–9.5) и MS SQL Server

Одна из самых мощных систем управления реляционными базами данных — IBM DB2, имеющая уникальные функции по масштабированию и поддерживающая множество платформ. Поставляется в нескольких редакциях, которые построены на одной базе и отличаются функционально. Архитектура баз данных DB2 позволяет управлять практически всеми типами данных: документами, XML, медиафайлами и так далее. Особо популярна бесплатная DB2 Express-C. Бэкап очень прост:

Или снапшот, использующий функцию Advanced Copy Services (ACS):

Но нужно помнить, что в случае снимков мы не можем восстанавливать (db2 recover db) отдельные таблицы. Есть и возможности по автоматическому бэкапу, и многое другое. Продукты хорошо документированы, хотя в русскоязычном интернете руководства встречаются редко. Также далеко не во всех специальных решениях можно найти поддержку DB2.

Работа мастера создания нового задания в Handy Backup

Работу с DB2 поддерживают две версии Handy Backup — Office Expert (локальный) и Server Network (сетевой). Работает на компьютерах под управлением Win8/7/Vista/XP или 2012/2008/2003. Сам процесс развертывания несложен для любого админа.

Копирование числовых ячеек из 1С в Excel Промо

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

Глоссарий терминов, связанных с резервным копированием

создание резервных копий
Процесс создания резервной копии путем копирования записей данных из базы данных SQL Server или записей журнала из ее журнала транзакций.

резервная копия
Копия данных, которая может использоваться для восстановления данных в случае возникновения ошибки. Резервные копии баз данных также могут использоваться для восстановления копии базы данных в новом расположении.

устройстворезервного копирования
Диск или ленточное устройство, на которые записываются резервные копии SQL Server для последующего восстановления. SQL Server резервные копии также можно записать в Хранилище BLOB-объектов Azure, а формат URL-адреса используется для указания назначения и имени файла резервной копии. Дополнительные сведения см. в статье SQL Server Резервное копирование и восстановление с помощью Microsoft Хранилище BLOB-объектов Azure.

носитель данных резервной копии
Одна магнитная лента или несколько или один файл на диске или несколько, в которые были записаны одна резервная копия или несколько.

резервное копирование данных
Резервная копия данных всей базы данных (резервная копия базы данных), части базы данных (частичная резервная копия) или набора файлов данных или файловых групп (резервная копия файлов).

резервное копирование базы данных
Резервная копия базы данных. Полные резервные копии базы данных отображают состояние всей базы данных на момент завершения резервного копирования. Разностные резервные копии базы данных содержат только изменения базы данных с момента последнего полного резервного копирования.

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

полная резервная копия
Резервная копия, которая содержит все данные заданной базы данных или наборов файлов или файловых групп, а также журналов для обеспечения возможности последующего восстановления этих данных.

резервная копия журналов
Резервная копия журналов транзакций, включающая все записи журнала, не входившие в предыдущую резервную копию журналов. (модель полного восстановления)

recover
Для возврата базы данных в стабильное и согласованное состояние.

recovery
Фаза запуска или восстановления базы данных, которая приводит базу данных в состояние согласованности транзакций.

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

восстановление
Многоэтапный процесс, в ходе которого все данные и страницы журнала копируются из указанной резервной копии SQL Server в определенную базу данных, а затем выполняется накат всех фиксированных транзакций, записанных в резервной копии журнала, путем внесения новых данных на основе зарегистрированных изменений.

Barman

Лицензия: GNU GPL

Поддерживаемые СУБД: PostgreSQL

PostgreSQL поддерживает возможности физического и логического бэкапа, добавляя к ним еще один уровень WAL (см. врезку), который можно назвать непрерывным копированием. Но управлять при помощи штатных инструментов несколькими серверами не очень удобно даже админу со стажем, а в случае сбоя счет идет на секунды.

Barman (backup and recovery manager) — внутренняя разработка компании 2ndQuadrant, предоставляющей услуги на базе PostgreSQL. Предназначен для физического бэкапа PostgreSQL (логический не поддерживает), архивирования WAL и быстрого восстановления после сбоев. Поддерживаются удаленный бэкап и восстановление нескольких серверов, функции point-in-time-recovery (PITR), управление WAL. Для копирования и подачи команд на удаленный узел используется SSH, синхронизация и бэкап при помощи rsync позволяет сократить трафик. Также Barman интегрируется со стандартными утилитами bzip2, gzip, tar и подобными. В принципе, можно использовать любую программу сжатия и архивирования, интеграция не займет много времени. Реализованы различные сервисные и диагностические функции, позволяющие контролировать состояние сервисов и регулировать полосу пропускания. Поддерживаются Pre/Post-скрипты.

Конфигурационный файл Barman
Другие статьи в выпуске:

Хакер #183. Малварь для Android

• Содержание выпуска
• Подписка на «Хакер»-60%

Barman написан на Python, управление политиками резервного копирования производится при помощи понятного INI-файла barman.conf, который может находиться в /etc или домашнем каталоге пользователя. В поставке идет готовый шаблон с подробными комментариями внутри. Работает только на *nix-системах. Для установки в RHEL, CentOS и Scientific Linux следует подключить EPEL — репозиторий, в котором содержатся дополнительные пакеты. В распоряжении пользователей Debian/Ubuntu официальный репозиторий:

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

Выводы

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

Если ЦОД встанет хотя бы на сутки, то это нанесёт огромный репутационный и финансовый ущерб владельцам, а также приведёт к оттоку клиентов. В марте 2021 года сгорел ЦОД хостинг-провайдера OVH в Страсбурге. Этот инцидент показал, что даже colocation в дата-центрах не даёт полной защиты. Поэтому всегда нужно иметь собственный DRP, хотя бы элементарный в заметках, чтобы не рвать волосы на голове в случае аварии — хотя и это иногда учитывают в DRP: отводят 15 минут на крики, панику и суету

Да, введение плана DRP в действие — это крайняя мера, к которой не хочется прибегать, но спать с закрытой дверью в доме спокойнее, чем без двери вовсе.