Уровень сплоченности коллектива зависит не только от количества совместно проведенного времени. Например, когда люди стоят даже много часов в очереди, они не сплачиваются. Сплоченность зависит, например, еще и от общих целей и ценностей. Например, можно почитать про факторы сплоченности в этой статье "Групповая сплоченность в организации".
Совершенно уместный вопрос, исходя из того как сформулированы в статье "4 обязательных условия" — там вообще нет ничего про должностные инструкции. На самом деле п.1 нужно дополнить — работодатель может выбрать: либо оформлять письменные служебные задания каждый раз, либо просто один раз письменно оформить должностную инструкцию (в которой отражена рабочая функция, например, "программирование" или "создание учебных курсов"), после чего служебные задания можно ставить, исходя из правил внутреннего распорядка компании или просто в соответствии с "обычаями делового оборота" (то есть, например, в устной форме, по email, или в виде документа с перечнем разрабатываемого функционала).
И п.4 также также надо уточнить — речь идет не о просто о дополнительном вознаграждении, а о вознаграждении, которое явно указано в договоре и в выплатах (см. расчетный листок) как "авторское вознаграждение" — оно уплачивается за сам факт передачи исключительных прав, и, таким образом, отличается по своему назначению от обычной зарплаты.
Данные можно сохранять в централизованном репозитории Veeam Backup & Replication уже в текущей версии Veeam Endpoint Backup for Windows. В версии Агента для Linux тоже будет такая возможность.
Касательно же централизованного управления — увы, для малых и средних инсталляций, пока нет готового решения от Veeam (но будет для крупных инсталляций) — у нас есть пост по этой теме, я процитирую из него без перевода:
Q: How can Veeam Agents be centrally deployed, managed and monitored?
A: Centralized job monitoring (via the Veeam Backup & Replication console) and reporting (via email notifications) is available for both free and licensed editions when backing up to a Veeam backup repository. Centralized deployment, configuration and management strategies depend on the deployment size:
Under 10 Veeam Agents: Manual deployment and management is recommended.
Above 10 Veeam Agents: Using remote configuration and management API available in licensed agents to automatically deploy and configure agents with logon scripts, Group Policy, SCCM, or whatever tool or method you have in place for software distribution is recommended.
Hundreds of Veeam Agents and multiple locations (hybrid cloud, remote offices, home offices, mobile users, etc.): Veeam Availability Console is recommended.
"К тому же нигде не написано, что резервное копирование данных должно производиться специализированными бэкаперами" — увы, но статья М.Ю. Емельянникова (ссылка №2 в разделе ссылок в моем посте) как раз содержательно (18 страниц) описывает в каких законах, приказах и постановлениях правительства это написано.
Да, ранее (до 2013 года) много лет резервное копирование данных считалось «общесистемной функцией», а не средством обеспечения защищенности системы, и на бэкап требования ФСТЭК не распространялись, потому что это не считалось средством защиты. Но приказы ФСТЭК 17, 21 и 31 отнесли бэкап к средствам защиты — для определенных систем и видов информации. Логика приказов состоит в том, что есть системы (например, в МЧС) для которых требуется государственный контроль за резервным копированием этих систем в виду их критичности. Или допустим вирус-шифровальщик зашифрует АСУ ТП на АЭС. Последствия могут быть плачевными, если нет бэкапа. Поэтому средства резервного копирования для определенных случаев были отнесены к средствам защиты, и стали подпадать под требования ФСТЭК к этим системам, что влечет необходимость сертификации в этих оговоренных в законодательстве случаях.
Касательно резервирования или отказоустойчивости самих СЗИ — насколько я знаю, у ФСТЭК нет явных требований к отказоустоячивости СЗИ, поэтому эти механизмы и могут оставаться несертифицированными. Эти механизмы предлагаются производителями не в силу требований ФСТЭК, а в силу ожиданий заказчиков (требований бизнеса).
Про vGate и SecretNet и меру ЗСВ.8.
SecretNet — это СЗИ от НСД, которое в среде виртуализации защищает от НСД только виртуальные машины и меру ЗСВ.8 не реализует. На хост ESX SecretNet вообще нельзя установить; на хост Hyper-V установить можно, но он будет защищать от НСД только сам физический хост, но не виртуальные машины и не среду виртуализации от угроз, которые специфичны для этой среды.
Про организационные меры и «любой бэкапер». Оргмеры — это, например, решетки на окнах, изоляция рабочего места от сети, и автоматчик на входе, проверяющий документы. Вне всяких сомнений подобными оргмерами можно заменить СЗИ от НСД, которые реализуют меры по аутентификации, авторизации и разграничению доступа. Но как решетки на окнах помогут пользователю выполнить требование на резервное копирование информации (ЗСВ.8)?
Особенность резервного копирования в том, что это не просто мера защиты (с 2013 года), а это еще и т.н. «функция общесистемного назначения», которая нужна пользователю системы вне зависимости от того, как строится система безопасности информации, и поэтому ее нельзя заменить оргмерами. Скажем, если объект критической инфраструктуры (например, АЭС) остановиться (=отключиться свет в ближайшем городе) из-за того, что не было бэкапа в АСУ ТП, потому что он был заменен «решетками на окнах», то ответственность за такой результат ляжет на системного администратора (условное название должности). Аналогичный результат будет, если в качестве бэкап продукта использовалась «условно-бесплатная программа» без сертификата, подтверждающего что ею можно бэкапить АСУ ТП на АЭС, и эта программа вдруг в нужный момент не отработала корректно.
Поэтому, использование сертифицированных продуктов там, где это требуется по закону, — это еще и способ снять ответственность с администратора системы за выбор технического решения.
Про компенсирующие меры. Тем не менее, я предположу, что вы на самом деле имели в виду не организационные, а “компенсирующие меры”, возможность применения которых указана в подпункте “д” пункта 2.3 методического документа ФСТЭК “меры защиты информации в государственных информационных системах”. Да, программно-техническую реализацию меры ЗСВ.8 (сертифицированный продукт) можно заменить в проекте безопасности компенсирующими мерами, для чего компания-проектировщик ИБ (с лицензией ФСТЭК) должна выполнить следующее:
Цитата из п. 2.3-д
При этом должно быть проведено обоснование применения компенсирующих мер защиты информации, включающее:
— изложение причин исключения меры (мер) защиты информации;
— сопоставление исключаемой меры (мер) защиты информации с блокируемой (нейтрализуемой) угрозой (угрозами) безопасности информации;
— описание содержания компенсирующих мер защиты информации;
— сравнительный анализ компенсирующих мер защиты информации с исключаемыми мерами защиты информации;
— аргументацию, что предлагаемые компенсирующие меры защиты информации обеспечивают адекватное блокирование (нейтрализацию) угроз безопасности информации.
Разработанное обоснование должно быть представлено при проведении аттестационных испытаний. При аттестационных испытаниях с учетом представленного обоснования должны быть оценены достаточность и адекватность компенсирующих мер для блокирования (нейтрализации) угроз безопасности информации.
Будет ли действительно дешевле это все спроектировать и выполнить, чем те 5%, на которые сертифицированный продукт стоит дороже не сертифицированного — это вопрос, который нужно считать в каждом конкретном случае.
Про деньги. Как я уже сказал, сертифицированная версия продукта стоит всего на 5% дороже обычной версии, а, поскольку резервное копирование типично требуется организации в любом случае, то нужно сравнивать именно эту наценку со стоимостью разработки проекта безопасности, в котором мера 3СВ.8 будет заменена компенсирующими мерами. Такие проекты тоже дешево не стоят (по крайней мере в Москве).
Увы, нет- в прайсе есть SKU только под новые продажи ФСТЭК версии. Логика здесь в том, что если у заказчика установлена обычная версия Veeam, то ему, вроде бы, незачем переходить на сертифицированную версию, так как она старее, а при этом сертификат, видимо, заказчику не обязателен.
Порядок подготовки обоснования невозможности закупки из Реестра подробно описан в этом же постановлении правительства ПП 1236 от 16.11.15.
На текущий момент в Реестре нет сертифицированных ФСТЭК продуктов для резервного копирования VMware vSphere и Microsoft Hyper-V. Сертификат ФСТЭК обязателен в описанных мною в посте случаях. Поэтому государственный заказчик в своем обосновании невозможности закупки из реестра, может прямо сослаться на пункт «а» в вашей цитате выше.
Дополнительно еще можно посмотреть в статье М.Ю. Емельянникова (ссылка №2 в разделе «ссылки» в моем посте) — в статье есть в конце раздел «что делать в эпоху импортозамещения».
А что конкретно интересует? Просто сама процедура сертификации в целом — довольно скучное бюрократическое мероприятие, которое, я полагал, не интересно читателям Хабра.
Бэкап физики будет полезен в первую очередь тем пользователям, которые уже выбрали Veeam для резервного копирования виртуализации, так как они получают возможность перейти на одного поставщика резервного копирования.
Разумеется, нет смысла менять текущий продукт резервного копирования физики, если он полностью устраивает.
Например, меня ранее не устраивала длительность окна резервного копирования физики, которую я делал с помощью одного из известных продуктов (не Veeam), и когда появился продукт от Veeam для физики, я перешел на него только для того, чтобы сократить это длинное backup window (примерно в 10 раз). Причина проста — схема Full+Incremental требовала мало времени только на инкрементальные проходы, но раз в неделю требовалось куча времени, чтобы выполнить Full. У Veeam же я использую схему «Forward Incremental-forever», которая полностью сняла проблему с длительностью полного бэкапа, так как всегда выполняются только инкрементальные бэкапы (плюс merge на стородже, который не потребляет ресурсы продуктивной системы).
Сразу после того, как in-place upgrade завершился с ошибками, не было варианта откатиться на последнюю точку восстановления, или загрузившись с загрузочного диска, запустить установщик старой WIndows Server 2003 в режиме сохранения установленной Windows?
по п.1 следующая ситуация. Успешность резервного копирования приложений определяется комбинацией функционала конкретного приложения и бэкап-продукта. Мы используем VSS, который был уже очень давно разработан Microsoft и все приложения должны его поддерживать, но реализация и качество реализации зависит от разработчика конкретного приложения.
Veeam Backup посылает VSS сообщение о том, что начинается бэкап-сессия. Все приложения, у которых разработчики реализовали VSS Writer, получают это сообщение и выполняют сброс буферов памяти на диск, в результате чего на диске получаются целостные файлы данных приложений. После этого Veeam Backup делает снапшот диска. Такой бэкап умеют делать Veeam Agent — Free и Workstation редакции.
Но некоторые приложения (SQL, Exchange) имеют транзакционный механизм внутри себя и пишут логи своих транзакций, чтобы иметь возможность самостоятельно откатывать изменения в своих файлах, не прибегая к средствам бэкап-продуктов. И таким приложениям нужно дополнительно сообщить, что снапшот диска прошел успешно, после чего они могут обрезать свои логи транзакций. Такое специальное сообщение умеет посылать только редакция Veeam Agent — Server. Кроме того, только ее и тестировали на таких кейсах, так как только она для них и предназначена.
Возвращаясь к вопросу: поскольку Outlook, на сколько мне известно, не пишет логов транзакций, связанных с PST (если там и есть транзакционность операций, то она внутри самого PST), то PST файл можно бэкапить Free и Workstation редакциями. Однако сбросит ли корректно свои кэши (если они есть) Outlook в PST на диск перед снапшотом или нет, зависит только от самого Outlook (его версии и версии ОС и других факторов).
Мне кажется обучение не будет работать, потому что хоть у нас и есть множество известных ключей по словарю, но зашифрованные данные будут каждый раз иметь вид случайного числа (если используются стандартные криптографические алгоритмы), поэтому невозможно оценить насколько мы ошиблись подбирая ключ. То есть проблема в том что невозможно оценить степень ошибки в значении каждого пробного ключа, а стало быть сеть не сможет учиться.
Так как Агент для Linux выполняется внутри виртуальной машины, он не использует снапшотов VMware. Используются снапшоты внутри виртуальной машины (для Linux написан собственный драйвер), Поэтому RDM поддерживается.
Аппаратные снапшоты СХД в первой версии еще не поддерживаются.
Microsoft спасла Apple не из-за ошибки — у Microsoft тогда шел суд с американской ФАС — ее хотели признать монополистом и могли принудительно потребовать разделить на несколько компаний. Такое уже было в 60-х годах в телефонной отрасли США. Microsoft как раз указывал в суде, что вот смотрите — есть сильный конкурент — Apple. Если бы Apple обанкротился, Microsoft проиграла бы суд. В итоге Microsoft выиграл суд, и продал акции Apple. А вот это уже считается огромной ошибкой, потому что впоследствии акции Apple выросли на порядок. :)
Уровень сплоченности коллектива зависит не только от количества совместно проведенного времени. Например, когда люди стоят даже много часов в очереди, они не сплачиваются. Сплоченность зависит, например, еще и от общих целей и ценностей. Например, можно почитать про факторы сплоченности в этой статье "Групповая сплоченность в организации".
Да, это будет в старшей редакции агента, "Server Edition":
"Авторские права" — это всё вместе (личные неимущественные права, исключительные права, право на вознаграждение и т.д.). См. 1255 ГК РФ.
Совершенно уместный вопрос, исходя из того как сформулированы в статье "4 обязательных условия" — там вообще нет ничего про должностные инструкции. На самом деле п.1 нужно дополнить — работодатель может выбрать: либо оформлять письменные служебные задания каждый раз, либо просто один раз письменно оформить должностную инструкцию (в которой отражена рабочая функция, например, "программирование" или "создание учебных курсов"), после чего служебные задания можно ставить, исходя из правил внутреннего распорядка компании или просто в соответствии с "обычаями делового оборота" (то есть, например, в устной форме, по email, или в виде документа с перечнем разрабатываемого функционала).
И п.4 также также надо уточнить — речь идет не о просто о дополнительном вознаграждении, а о вознаграждении, которое явно указано в договоре и в выплатах (см. расчетный листок) как "авторское вознаграждение" — оно уплачивается за сам факт передачи исключительных прав, и, таким образом, отличается по своему назначению от обычной зарплаты.
Данные можно сохранять в централизованном репозитории Veeam Backup & Replication уже в текущей версии Veeam Endpoint Backup for Windows. В версии Агента для Linux тоже будет такая возможность.
Касательно же централизованного управления — увы, для малых и средних инсталляций, пока нет готового решения от Veeam (но будет для крупных инсталляций) — у нас есть пост по этой теме, я процитирую из него без перевода:
Q: How can Veeam Agents be centrally deployed, managed and monitored?
A: Centralized job monitoring (via the Veeam Backup & Replication console) and reporting (via email notifications) is available for both free and licensed editions when backing up to a Veeam backup repository. Centralized deployment, configuration and management strategies depend on the deployment size:
Veeam AAIP сохраняет статус приложений (которые имеют Microsoft VSS writers) во всех описанных случаях.
Да, ранее (до 2013 года) много лет резервное копирование данных считалось «общесистемной функцией», а не средством обеспечения защищенности системы, и на бэкап требования ФСТЭК не распространялись, потому что это не считалось средством защиты. Но приказы ФСТЭК 17, 21 и 31 отнесли бэкап к средствам защиты — для определенных систем и видов информации. Логика приказов состоит в том, что есть системы (например, в МЧС) для которых требуется государственный контроль за резервным копированием этих систем в виду их критичности. Или допустим вирус-шифровальщик зашифрует АСУ ТП на АЭС. Последствия могут быть плачевными, если нет бэкапа. Поэтому средства резервного копирования для определенных случаев были отнесены к средствам защиты, и стали подпадать под требования ФСТЭК к этим системам, что влечет необходимость сертификации в этих оговоренных в законодательстве случаях.
Касательно резервирования или отказоустойчивости самих СЗИ — насколько я знаю, у ФСТЭК нет явных требований к отказоустоячивости СЗИ, поэтому эти механизмы и могут оставаться несертифицированными. Эти механизмы предлагаются производителями не в силу требований ФСТЭК, а в силу ожиданий заказчиков (требований бизнеса).
Касательно «возможности делать бэкап руками» (т.н. «компенсирующие меры»), смотрите этот мой ответ на другой комментарий.
Про vGate и SecretNet и меру ЗСВ.8.
SecretNet — это СЗИ от НСД, которое в среде виртуализации защищает от НСД только виртуальные машины и меру ЗСВ.8 не реализует. На хост ESX SecretNet вообще нельзя установить; на хост Hyper-V установить можно, но он будет защищать от НСД только сам физический хост, но не виртуальные машины и не среду виртуализации от угроз, которые специфичны для этой среды.
vGate реализует меры ЗСВ.1- ЗСВ.7 и ЗСВ.10, и НЕ реализует меру ЗСВ.8 — например, можете это посмотреть в документе RISSPA “Проблема выбора средств защиты информации для виртуализированных инфраструктур”:
Про организационные меры и «любой бэкапер». Оргмеры — это, например, решетки на окнах, изоляция рабочего места от сети, и автоматчик на входе, проверяющий документы. Вне всяких сомнений подобными оргмерами можно заменить СЗИ от НСД, которые реализуют меры по аутентификации, авторизации и разграничению доступа. Но как решетки на окнах помогут пользователю выполнить требование на резервное копирование информации (ЗСВ.8)?
Особенность резервного копирования в том, что это не просто мера защиты (с 2013 года), а это еще и т.н. «функция общесистемного назначения», которая нужна пользователю системы вне зависимости от того, как строится система безопасности информации, и поэтому ее нельзя заменить оргмерами. Скажем, если объект критической инфраструктуры (например, АЭС) остановиться (=отключиться свет в ближайшем городе) из-за того, что не было бэкапа в АСУ ТП, потому что он был заменен «решетками на окнах», то ответственность за такой результат ляжет на системного администратора (условное название должности). Аналогичный результат будет, если в качестве бэкап продукта использовалась «условно-бесплатная программа» без сертификата, подтверждающего что ею можно бэкапить АСУ ТП на АЭС, и эта программа вдруг в нужный момент не отработала корректно.
Поэтому, использование сертифицированных продуктов там, где это требуется по закону, — это еще и способ снять ответственность с администратора системы за выбор технического решения.
Про компенсирующие меры. Тем не менее, я предположу, что вы на самом деле имели в виду не организационные, а “компенсирующие меры”, возможность применения которых указана в подпункте “д” пункта 2.3 методического документа ФСТЭК “меры защиты информации в государственных информационных системах”. Да, программно-техническую реализацию меры ЗСВ.8 (сертифицированный продукт) можно заменить в проекте безопасности компенсирующими мерами, для чего компания-проектировщик ИБ (с лицензией ФСТЭК) должна выполнить следующее:
— изложение причин исключения меры (мер) защиты информации;
— сопоставление исключаемой меры (мер) защиты информации с блокируемой (нейтрализуемой) угрозой (угрозами) безопасности информации;
— описание содержания компенсирующих мер защиты информации;
— сравнительный анализ компенсирующих мер защиты информации с исключаемыми мерами защиты информации;
— аргументацию, что предлагаемые компенсирующие меры защиты информации обеспечивают адекватное блокирование (нейтрализацию) угроз безопасности информации.
Разработанное обоснование должно быть представлено при проведении аттестационных испытаний. При аттестационных испытаниях с учетом представленного обоснования должны быть оценены достаточность и адекватность компенсирующих мер для блокирования (нейтрализации) угроз безопасности информации.
Будет ли действительно дешевле это все спроектировать и выполнить, чем те 5%, на которые сертифицированный продукт стоит дороже не сертифицированного — это вопрос, который нужно считать в каждом конкретном случае.
Про деньги. Как я уже сказал, сертифицированная версия продукта стоит всего на 5% дороже обычной версии, а, поскольку резервное копирование типично требуется организации в любом случае, то нужно сравнивать именно эту наценку со стоимостью разработки проекта безопасности, в котором мера 3СВ.8 будет заменена компенсирующими мерами. Такие проекты тоже дешево не стоят (по крайней мере в Москве).
На текущий момент в Реестре нет сертифицированных ФСТЭК продуктов для резервного копирования VMware vSphere и Microsoft Hyper-V. Сертификат ФСТЭК обязателен в описанных мною в посте случаях. Поэтому государственный заказчик в своем обосновании невозможности закупки из реестра, может прямо сослаться на пункт «а» в вашей цитате выше.
Примеры написания таких обоснований (и письменная работа с возражениями) для более сложного случая (пункт «б») в настоящий момент можно посмотреть на сайте госзакупок, например, закупка «Оказание услуг по предоставлению (продлению) неисключительных прав (лицензий) на использование программного обеспечения Microsoft». Кроме того, недавно опубликована подробная статья еще с одним примером:«Windows и SQL Server против российских аналогов: Результаты анализа ФОМС»
Дополнительно еще можно посмотреть в статье М.Ю. Емельянникова (ссылка №2 в разделе «ссылки» в моем посте) — в статье есть в конце раздел «что делать в эпоху импортозамещения».
Разумеется, нет смысла менять текущий продукт резервного копирования физики, если он полностью устраивает.
Например, меня ранее не устраивала длительность окна резервного копирования физики, которую я делал с помощью одного из известных продуктов (не Veeam), и когда появился продукт от Veeam для физики, я перешел на него только для того, чтобы сократить это длинное backup window (примерно в 10 раз). Причина проста — схема Full+Incremental требовала мало времени только на инкрементальные проходы, но раз в неделю требовалось куча времени, чтобы выполнить Full. У Veeam же я использую схему «Forward Incremental-forever», которая полностью сняла проблему с длительностью полного бэкапа, так как всегда выполняются только инкрементальные бэкапы (плюс merge на стородже, который не потребляет ресурсы продуктивной системы).
Veeam Backup посылает VSS сообщение о том, что начинается бэкап-сессия. Все приложения, у которых разработчики реализовали VSS Writer, получают это сообщение и выполняют сброс буферов памяти на диск, в результате чего на диске получаются целостные файлы данных приложений. После этого Veeam Backup делает снапшот диска. Такой бэкап умеют делать Veeam Agent — Free и Workstation редакции.
Но некоторые приложения (SQL, Exchange) имеют транзакционный механизм внутри себя и пишут логи своих транзакций, чтобы иметь возможность самостоятельно откатывать изменения в своих файлах, не прибегая к средствам бэкап-продуктов. И таким приложениям нужно дополнительно сообщить, что снапшот диска прошел успешно, после чего они могут обрезать свои логи транзакций. Такое специальное сообщение умеет посылать только редакция Veeam Agent — Server. Кроме того, только ее и тестировали на таких кейсах, так как только она для них и предназначена.
Возвращаясь к вопросу: поскольку Outlook, на сколько мне известно, не пишет логов транзакций, связанных с PST (если там и есть транзакционность операций, то она внутри самого PST), то PST файл можно бэкапить Free и Workstation редакциями. Однако сбросит ли корректно свои кэши (если они есть) Outlook в PST на диск перед снапшотом или нет, зависит только от самого Outlook (его версии и версии ОС и других факторов).
Аппаратные снапшоты СХД в первой версии еще не поддерживаются.