Милі та пухнасті

Author: admin

  • Три категории уязвимости ПО

    В течение почти двух десятилетий кибер-злоумышленники получали прибыль от организаций, используя уязвимое программное обеспечение через Интернет. Как следствие организации пытались защитить своё уязвимое программное обеспечение множеством различных технологий, которые подпадают под  категорию зонт «безопасности программного обеспечения».  Антивирусные решения, DDoS защитные устройства, брандмауэры нового поколения, DMZ и системы предотвращения вторжений, брандмауэрам веб-приложений (WAF), решениям по управлению ботами, самозащита приложений во время выполнения (RASP), балансировщики нагрузки и множество других технологий, ни одна из которых на самом деле не решает корень проблемы, причина почти каждой успешной кибератаки – уязвимое программное обеспечение.
    Продукты, упомянутые выше, пытаются управлять и контролировать кибератаки, но ни одно из них не может найти и исправить множество эксплуатируемых уязвимости в программном обеспечении. Попытка защитить уязвимое программное обеспечение, используя внешние приложения просто терпят неудачу. Eсть лучший способ защиты программного обеспечения, путем тестирования, поиска,
    и устранение уязвимостей, что приводит к созданию более безопасных программное обеспечение. В следующем разделе описывается, как это можно сделать сегодня.

    Категории уязвимости ПО

    Хотя наиболее распространенные недостатки программного обеспечения (или ошибки программного обеспечения) перечислены в OWASP Top 10 и SANS Top 25, все эти списки можно разбить на три основные категории уязвимостей,:

    • Нескомпилированный код
    • Запуск кода
    • Компоненты с открытым исходным кодом

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

    Разные AST решения находят разные Уязвимости программного обеспечения

    Решения статического тестирования безопасности приложений  Static Application Security Testing (SAST) используются для
    постепенно сканировать (тестирования) некомпилированного кода на наличие уязвимостей во время всего процесса разработки программного обеспечения в Dev. Когда код все еще в своем некомпилированном состоянии, статическое тестирование предназначено для поиска недостатков, таких как SQL-инъекция. SAST решения хороши, они предоставляют информацию на уровне кода относительно того, где и как исправить уязвимости в исходном коде. SAST хорошо вписывается в интегрированные среды разработки (IDE), имеет трекеры и инструменты для поддержки рабочих процессов CI / CD. SAST хорошо подходит для DevOps, так как он не вносит значительных задержек в выпуск ПО.

    Решения для интерактивного тестирования безопасности приложений Interactive Application Security Testing (IAST) помогает обнаружить недостатки конфигурации во время деплоя приложения, выявленные во время функционального тестирования. Не обоснована предполагать, что приложения не содержат уязвимостей после фазы разработки, и код не нуждается в проверке. IAST понимает, как все части приложения работают вместе и работают во время выполнения, поэтому может обнаружить уязвимости в запущенных приложениях, которые могут использовать злоумышленники. IAST хорошо вписывается в DevOps, поскольку он не имеет значительных задержек, для проведения функционального тестирования.

    Решения для анализа программного обеспечения Software Composition Analysis (SCA) расширяют возможности для группы разработки, безопасности и эксплуатации, определения рисков, связанных с открытым исходным кодом в программном обеспечение, которое они пишут, деплоят и поддерживают. Анализ и управление компонентами с открытым исходным кодом гарантирует, что уязвимые компоненты будут удалены или заменены прежде чем они станут проблемой. SCA хорошо вписывается в DevOps, так как не вносит значительных задержек.

    Средства динамического тестирования безопасности приложений Dynamic Application Security Testing (DAST) обнаруживают
    уязвимости в работающем приложений от внешних атак. DAST ограничено отражающими типами уязвимости, поскольку решения DAST по сути слепы, к тому что происходит внутри приложения. В результатах теста DAST, нет указаний на уровне кода, относительно того, где расположены уязвимости программного обеспечения, что затрудняет разработчикам легко исправить выявленные уязвимости. Инструменты DAST не могут обеспечить быстрые сроки выполнения работ. DAST плохо вписывается в DevOps так как это часто приводит к длительным задержкам.

  • Безопасность в devops продолжение

    Начало в статье.

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

    Обратите внимание на Open Source уязвимости в DevOps

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

    Проблема сложности кода в DevOps

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

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

    Решение проблем с программным обеспечением пока не влияет на скорость

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

  • Современный подход к безопасности DevOps

    Современный подход к безопасности DevOps

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

    Современный подход к безопасности в DevOps

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

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

    Второй тип тестирования известен как Тестирование безопасности приложений (AST), и именно здесь выявляются уязвимости, сопоставляются результаты, и должны быть устранены уязвимости до выпуска программного обеспечения. Сегодня и во многих средах DevOps,
    оба типа тестирования (функциональное и AST) выполняются на этапе Test / QA. И здесь нужна скорость и проверка безопасности, как правило, конфликтуют. Причина этого в том, что AST не было встроено в весь процесс разработки. Вместо этого и
    в большинстве случаев AST существует только в одном месте – в точке перехода где программное обеспечение перемещается из Dev в Ops, часто создавая узкое место, которое вызывает задержки.

    Команды разработчиков ориентированы на время выхода на рынок. Команды AppSec управляют безопасностью уже работающего программного обеспечения. Вот тут и происходит балансировка. AST не может отложить развертывание, зачастую время релиза важнее безопасности. В CI/CD добавлены задержки для AST, которые дают возможность выявить и устранить некоторые уязвимости. Должен быть лучший способ выполнения AST на протяжении всего процесса DevOps, который бы не вызывал задержек.
    В следующем разделе мы обсудим лучший подход.

    Лучший подход к безопасности в DevOps

    Существует способ встраивания решений AST во все этапы разработки, но как это сделать? На рисунке 4 концепция сдвига в центр может иметь больший смысл.

    Как показано на рисунке 4, решения AST могут быть встроены в этапы Dev, сборку и тестирование / контроль качества. Давайте
    перечислим некоторые из доступных решений AST на рынке сегодня.

    AST Solutions:

    • SAST – статическое тестирование безопасности приложений
    • IAST – Комплексное тестирование безопасности приложений
    • SCA – Анализ состава программного обеспечения
    • DAST – динамическое тестирование безопасности приложений

    В следующих статьях более детально рассмотрим доступные решения AST. Продолжение

  • Devops и безопасность

    Devops и безопасность

    Поскольку Agile подходы стали более распространенным явлением, начал наблюдаться прогресс. Как только команды разработчиков (Dev) завершали свою работу, проект стал передаваться операционной команде (Ops) для развертывания, поддержки и текущего обслуживания. Тем не менее, по опыту той ранней эпохи были проблемы в том, что программное обеспечение часто работать нормально в среде разработчиков, но у него были проблемы с запуском продуктиве. Это создало много трений между командами разработчиков и Ops командами, так как ни одна команда не имела глубоких знаний о том, чем занимается другая команда.
    Ближе к концу 2000-х годов в отрасли началось рождение DevOps благодаря группе заинтересованных сторон, которые начали совещаться о том, как построить лучшую связь между командами разработчиков и Ops; были созданы новые практики, которые привели к сдвигу в традиционном мышлении. DevOps движение создало культуру и атмосферу, в которой разработка, тестирование и доставка программного обеспечения должны были выполнятся быстро, регулярно и с большей надежностью. Этот культурный сдвиг привел к началу появления непрерывной интеграции (CI) и непрерывной доставки (CD), которые сегодня являются частью современного DevOps, как показано на рисунке
    По сути, DevOps – это процессы, соединения, инструментов автоматизация на протяжении всей этапов: разработки, тестирования и доставки ПО. Но что более важно, DevOps – это инструменты автоматизации и другие инструменты, связанных с с созданием программного обеспечения. Тем не менее, одна вещь, которую DevOps не смог решить самостоятельно, как встраивать безопасность программного обеспечения на всех этапах развития программного обеспечения. Что касается безопасности программного обеспечения в обоих Agile и DevOps, было много болтовни о новом методе добавления безопасности в эти среды, называемом «сдвиг влево». Дальше рассмотрим эту концепцию.

    Сдвиг влево против сдвига в центр

    В индустрии разработки программного обеспечения термин «сдвиг влево» всплыл в результате организации, ожидания тестирования безопасности до конца процесса разработки, часто вызывая неожиданные задержки. Если вы тестируете свое программное обеспечение в поисках уязвимости безопасности в конце процесса разработки (справа), то существует рекомендация – сдвинуть тестирование дальше налево и быстрее провести тестирование безопасности – для сокращение задержек. Тем не менее, это имеет очень мало смысла в целом, так как DevOps не линейный, как методология Waterfall. DevOps это имеет круговую форму, как показано довольно хорошо на рисунке ниже.
    Как видно на рисунке, DevOps на самом деле не имеет ни левой ни правой стороны в сравнении с более линейными процессами, используемыми в Waterfall. Вы скажите Dev слева и Ops справа, но DevOps больше похоже на петлю бесконечности у которой нет ни начала, ни конца.
    Процесс Dev никогда не останавливается, и процесс Ops никогда не останавливается.
    Лучшей рекомендацией будет смещение центра. Встраивать программные решения по безопасности в DevOps. Что ж
    более подробно сдвиг в центр мы рассмотрим в следующей статье. Однако здесь это аналогия, которая может помочь лучше понять концепцию «сдвиг влево» и почему он не подходит для DevOps.

    Линейный vs Круглый

    Когда вы в поезде, и кто-то хочет сесть на поезд, что делает поезд? Поезд останавливается, пассажиры садятся,
    и пассажиры выходят. Затем поезд начинает двигаться, только чтобы сделать то же самое дальше по дороге. Это не то что мы хотим для внедрения безопасности программного обеспечения в наши инициативы DevOps, скорее всего это будет не эффективно. Весь смысл CI и CD в том, что поезд никогда не должен останавливаться, и сдвиг влево просто не подходит. Вместо этого давайте посмотрите на лучшую аналогию, которая может намекнуть на новый метод добавления
    безопасности в процессах DevOps.
    Колесо обозрения London Eye – одно из самых высоких колес в мире. Интересная информация о London Eye – то, что когда аттракцион работает то движение колеса обозрения никогда не останавливается несмотря на то, есть ли пассажиры или нет. Люди встают, люди выходят, но колесо продолжает без колебаний вращаться. Никто в поездке не знает, кто сел или кто вышел, так как с точки зрения человека который едит на нем, нет никакого воздействия на его езду. Это способ, которым организации должны подумайте о том, чтобы добавить безопасность в программную среду DevOps –
    способ, который никогда не останавливает процесс.
    Концепция «сдвига влево» не подходит, поскольку это не имеет смысла, когда наблюдаешь знак бесконечности цикла на рисунке. Следовательно, как организации должны внедрять безопасность в DevOps? В следующем разделе рассмотрим это.

  • Безопасность в Agile проектах

    В предыдущей статье мы ознакомились с безопасностью в Waterfall проектах, продолжаем рассматривать дальше.
    Было ясно, что нужна лучшая методология, которая могла бы включить безопасность в процессы разработки, но был ли Agile создан для решения проблемы безопасности? Не обязательно так.
    Agile стал решением линейно-основанных недостатков методология Waterfall. В 2001 году группа влиятельных лиц решила
    переосмыслить разработку программного обеспечения и в результате был сформирован Agile Манифест.
    Весь смысл Agile заключался в создании Agile (реагировать на изменить) среду, которая не воспроизводит полностью линейную, негибкую, конвейерную методологию waterfall. Самое важная характеристика Agile методологий позволила разработчикам стать более гибким в изменениях в течение всего процесса, на основе итерационных (повторяющихся)
    действий. Сотрудничество между кросс-функциональными командами было высоко подчеркнуто в Agile методологии, так как она дала людям возможность принимать командные решения и приспосабливаться к постоянному тестированию и изменению требований к каждой интеграции.

    Появление Software Security Sandwich

    Удалено: В методологиях Wterfall и Agile есть много связанных с безопасностью действий на этапе формирования бизнес-требований и технического проектирования. Тестирования безопасности программного обеспечения перед выпуском в продашн. Эти два этапа проверки на безопасность программного обеспечения, привели к появлению так называемой
    Удалено: сэндвич безопасности. Хотя Agile был широко принят и используется командами разработчиков по всему
    Удалено: миру, это все еще не эффективное решение безопасности программного обеспечения, которое существовало в Waterfall. Software Security Sandwich все еще существует, потому что организации не интегрировали безопасность на всех этапах разработки программного обеспечения. Agile, безусловно, помогает решить переходный характер сегодняшних бизнес-циклов, но он все еще не ставит безопасность в приоритете.

  • Безопасность в Waterfall проекте

    Безопасность в Waterfall проекте

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

    На протяжении десятилетий были организованы этапы разработки программного обеспечения с использованием так называемой методологии водопада Waterfall.
    Общая задача была организована в несколько этапов, которая очень напоминала сборочный конвейер, благодаря успешному производству товар постоянного качества, по самой низкой цене. Сборочная линия была очень линейной по своей природе и все, что замедляло или останавливало линия приравнивалось к потерям производства и выручки. Тем не менее, где добавить безопасность в рамках методологии Waterfall?
    Традиционно команды Application Security (AppSec) работали с командами разработчиков программного обеспечения на двух этапах: технические требования, дизайн, и прямо перед тем, как программное обеспечение было запланировано к выпуску в продакшн. После того, как команда проекта собрала бизнес-требования и определили целевую архитектуру, затем их проект пошел в AppSec команде для обзора. Этот обзор обычно включает некоторые формы моделирования угрозы при обмене данными. После завершения формировался список требования по безопасности, и они добавлялись в проектный документ. Документ передавался команде разработки, которые в свою очередь работали над разработкой приложений следующие несколько месяцев (или дольше).
    После того, как у команд разработчиков было рабочее приложение, которое отвечало задокументированным требованиям, и пользователи подтверждали, что это то, что им необходимо, команда проекта снова взаимодействует с командами AppSec. Работая в качестве шлюза безопасности, команды AppSec запускают различные тесты на проникновение, чтобы найти уязвимости безопасности в финальном продукте. Они формируют длинный список уязвимостей, которые должны быть исправлены до выпуска программного обеспечения в продакшн, и это останавливало конвейер разработки.
    См. Рис. 1 ниже, где показано расположение шлюза безопасности в методологии Waterfall.

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

  • Penetration Testing Report

    Penetration Testing Report

    Организация “XXX” заключила соглашение с “ITFB.com.ua” на проведение теста на проникновение для определения склонности сайтов https://XXX.tools и https://XXX2.tools к уязвимостям.

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

    ● Раскрыть базу данных пользователей и получить возможность влиять на количество голосов при проведении голосования за проекты.
    Также была поставлена ​​дополнительная цель:
    ● Убедиться в надежности защиты ресурсов перед их запуском в рабочую эксплуатацию.
    Были предприняты усилия по выявлению и использованию слабых мест безопасности, которые могут позволить удаленным злоумышленникам получить несанкционированный доступ к данным расположенных на ресурсах.
    Атаки проводились с уровнем доступа, который должен иметь обычный пользователь Интернета.
    Все испытания и действия проводились в контролируемых условиях.

     

    Инициация атаки

    Исследование
    Получение информации и определения векторов атаки.
    В попытке определить потенциальную поверхность атаки мы исследовали общие записи DNS для доменов xxx.tools и xxx2.tools
    Намерение состояло в том, чтобы тщательно симулировать поведение злоумышленника без какой-либо внутренней информации.

    Рисунок 1.  Идентификация DNS записей

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

     

    Рисунок 2. Проверка конфигурации зон DNS.
    Далее мы проверили наличие уязвимостей в веб-окружении сервера https://xxx.tools и обнаружили использование устаревшей и склонной к уязвимостей версии “Rails”, которая позволяет с помощью удаленного использования произвольного кода – читать конфиденциальную информацию из файлов расположенных на сервере любому не авторизованному в системе пользователю.


    Рисунок 3. Пример HTTP запроса для получения списка системных учетных записей


     
    Рисунок 4. Ответ сервера содержит список системных учетных записей

    Веб-окружение сервера https://ххх.tools использует уязвимую версию библиотеки Javascript “jQuery” 1.12.4 в следующем скрипте.

    Рисунок 5. Проверка версии jQuery.

    Страница входа на ресурс https://ххх.ua/users/sign_in была протестирована многочисленными попытками входа под одним и тем же пользователем. Мы обнаружили, что страница не защищена от попыток подбора пароля (brute force). Дополнительно рекомендуется реализовать блокировку учетной записи после определенного количества попыток ввода неверного пароля.


    Рисунок 6. Многочисленные попытки авторизации

    Ресурс https://ххх.tools содержит * .css файлы, содержание которых раскрывает конфиденциальную информацию о внутренней файловой структуры сервера.

    Рисунок 7. Раскрытие внутренней структуры сервера
    По этой информации злоумышленник получает точное расположение web-приложения в файловой системе на сервере и может использовать это для дальнейших атак.
    Попытки выполнить различные типы “XSS” или “CSRF” на ресурсах – не дали удовлетворительного результата. Ресурсы не склонны к этому типу уязвимостей.

    Рейтинг безопасности

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

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

    Средняя степень

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

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

    Рекомендации

    • Обновить “jQuery” до актуальной версии или применить патч https://github.com/jquery/jquery/issues/2432
    • Обновить” Ruby on Rails “до актуальной версии или применить патч
      https://groups.google.com/forum/#!topic/rubyonrails-security/pFRKI96Sm8Q
    • Запретить отображение конфиденциальной информации в css файлах для пользователей ресурса

    Вывод

    Конкретные цели теста на проникновение были сформулированы следующим образом:

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

    Цели теста на проникновение не были достигнуты, потому что ресурсы имеют достаточную степень защиты на данный момент от подобных атак.

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

  • Ваша компания готова к карантину?

    Ваша компания готова к карантину?

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

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

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

    Готова ваша компания пережить короновирус?

    Вы уже знаете ответ на этот вопрос? Если нет то пора задуматься, как минимизировать последствия. Речь конечно не идет об организациях где задействован физический труд человека, им помочь ИТ технологии вряд-ли смогут, по крайней мере для них нет быстрого решения. У Вас есть офис и сотрудники работают в основном за ПК – тогда Вам повезло, можно всех отправить работать дома. А так ли это? Сразу возникает вопросы, а как они подключаться к корпоративной почте, зайдут в 1С, BI, сделают отчеты и все остальное? Тут могут быть варианты, все зависит от ИТ инфраструктуры реализованной в Вашем предприятии.

    Варианты ИТ инфраструктур

    вид ИТ инфраструктуры облачная наземная гибридная
    удаленный доступ к почте есть зачастую нет зависит от решения
    удаленный доступ к файловому ресурсу есть зачастую нет зависит от решения
    удаленный доступ к бухгалтерскому по есть зачастую нет зависит от решения
    уделенный доступ к совместным ресурсам есть зачастую нет зависит от решения
    удаленный доступ к crm системам есть зачастую нет зависит от решения
    можно организовать удаленную работу из дома да да да

    Немного терминологии простыми словами:

    • Облачная – инфраструктура у которой все сервисы в облаке. Например вы пользуетесь office 365, outlook, lync. В Azure размещены виртуальные машины с сервисами для работы. Здесь вопросов с удаленной работой практически не возникает. Хотя обязательно нужно позаботится о безопасности данных, использовать двойные методы авторизации и т.п.
    • Наземная – инфраструктура, которая расположена у Вас в офисе, в серверной, к такой инфраструктуре также относятся и размещение серверов у провайдеров, или их аренда в дата центе. Если используете дата центр, то организовать удаленною работу офиса не составит труда. А вот если сервер стоит в офисе нужно проделать небольшую работу, для организации к нему удаленного доступа сотрудников.
    • Гибридная – это комбинация из наземных и облачных сервисов.

    В любом случае рекомендую такие действия для понимания насколько офис готов работать удаленно:

    1. Провести ИТ аудит сервисов, определить какая у Вас инфраструктура
    2. Провести работы по настройки удаленного доступа к сервисам предприятия
    3. Обязательно позаботится о настройки безопасности удаленного доступа
    4. Определить список сотрудников, которых можно отправить на удаленную работу
    5. Собрать информацию о девайсах сотрудников, возможно некоторым нужно будет выдать рабочие ноутбуки, а кто-то сможет работать с домашнего ПК
    6. Разработать план мероприятий для перехода работы офиса из дома

    Таким образом на случай массового карантина Вы сможете минимизировать потери от простоя работы.

    Если Вы не знаете как организовать удаленный доступ к сервисам и организовать работу офиса из дома, обращайтесь к нашим специалистам, дадим консультацию, проведем аудит, поможем в реализации, office@itfb.com.ua или раздел контакты.

    организация удаленного доступа

  • EKS vs GKE vs AKS – оценка Kubernetes в облаке

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

    Мы подробно рассмотрели текущие функции и ограничения управляемых услуг Kubernetes от трех крупнейших поставщиков облачных услуг: Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS) и Google Kubernetes Engine (GKE). Мы надеемся, что, представляя эту информацию последовательно, как нынешние пользователи Kubernetes, так и потенциальные пользователи могут выбрать подходящие варианты или получить обзор текущего состояния управляемых Kubernetes.
    Несмотря на то, что мы затрагиваем такие важные темы, как доступность версий, параметры сети и безопасности, а также накладные расходы на управление, мы не отталкиваемся от различий в цене и производительности. Вся информация была актуальной по состоянию на 10 февраля 2020 года.

    Общая информация

    Amazon EKS Microsoft AKS Google GKE Kubernetes
    Поддерживаемые версии Kubernetes
    • 1.14 (по умолчанию)
    • 1,13
    • 1,12
    • 1.17 ( превью )
    • 1.16 ( превью )
    • 1,15
    • 1.14 (по умолчанию)
    • 1,13
    • 1.16 ( быстрый канал – бета )
    • 1,15
    • 1,14
    • 1.13 (по умолчанию)
    • 1,18 ( альфа )
    • 1,17
    • 1,16
    • 1,15
    # поддерживаемых минорных версий ≥3 + 1 устарела 3 2-3 3
    Дата выхода оригинальной GA Июнь 2018 Июнь 2018 Август 2015 Июль 2015 (Kubernetes 1.0)
    CNCF Kubernetes соответствие да да да да
    Последняя версия, сертифицированная CNCF 1,14 1,14 1,14 –
    Мастер обновления Инициация пользователем; пользователь также должен вручную обновить системные службы, работающие на узлах (например, kube-proxy, coredns, AWS VPC CNI) Инициация пользователем Автоматически обновляется во время обслуживания кластера; может быть инициировано пользователем –
    Процесс обновления узла
    • Неуправляемые группы узлов: все инициируемые пользователем и управляемые
    • Группы управляемых узлов: инициируемые пользователем; EKS будет сливать и заменять узлы
    		 Инициация пользователем; AKS будет сливать и заменять узлы Автоматически обновляется (по умолчанию; может быть отключен) во время обслуживания кластера; может быть инициировано пользователем; GKE истощает и заменяет узлы –
    Запуск контейнера Docker Moby Docker
    • Докер (по умолчанию)
    • containerd
    • Linux: Docker, containerd, cri-o, rktlet, любая среда выполнения, реализующая интерфейс Kubernetes CRI (интерфейс среды выполнения контейнера)
    • Windows: Docker EE-basic 18.09
    Варианты высокой доступности master/ control plane Плоскость управления развернута в нескольких зонах доступности В документах Azure не указываются меры избыточности для плоскости управления
    • Зональные / многозонные кластеры: единая плоскость управления
    • Региональные кластеры: реплики плоскости управления в нескольких зонах
    		 поддерживает
    Master (control plane) SLA 99,9% 99,5%
    • Зональные кластеры: 99,5%
    • Региональные кластеры: 99,95%
    		 –
    SLA с финансовой поддержкой да нет нет –
    Стоимость $0,10 / час (USD) за кластер + стандартные затраты на экземпляры EC2 и другие ресурсы Стандартные затраты на виртуальные машины узлов и другие ресурсы Стандартные затраты на машины GCE и другие ресурсы –
    Поддержка GPU Да (NVIDIA); пользователь должен установить плагин устройства в кластере Да (NVIDIA); пользователь должен установить плагин устройства в кластере Да (NVIDIA); пользователь должен установить плагин устройства в кластере Поддерживается с плагинами устройства
    Логи основного компонента Необязательно, по умолчанию отключено; Отправляются в AWS CloudWatch Необязательно, по умолчанию отключено; Отправляются в Azure Monitor Необязательно, по умолчанию включено; Отправляются в Stackdriver –
    Метрики производительности контейнера Необязательно, по умолчанию отключено; Отправляются в AWS CloudWatch Container Insights Необязательно, по умолчанию отключено; Отправляются в Azure Monitor ( предварительный просмотр ) Необязательно, по умолчанию включено; Отправляются в Stackdriver –
    Мониторинг узла Нет поддержки со стороны Kubernetes; в случае сбоя экземпляра узла группа автоматического масштабирования AWS пула узлов заменит его Нет Авто-восстановление узла включено по умолчанию –

    Комментарии

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

    Наиболее заметное различие касается фактического управления, которое различные провайдеры делают для своих управляемых услуг. Здесь GKE явно играет ведущую роль, предлагая автоматические обновления для мастеров и узлов, а также обнаружение и исправление нездоровых узлов. Обновления EKS и AKS требуют, по крайней мере, некоторой степени ручной работы (или, запрограммированной клиентом автоматизации), особенно на EKS. Кроме того, ни EKS, ни AKS не предлагают какого-либо специализированного узла мониторинга состояния или восстановления. Клиенты AWS могут создавать настраиваемые проверки работоспособности для выполнения определенной степени мониторинга работоспособности узлов и автоматической замены клиентов для кластеров EKS, но AKS не предлагает сопоставимых функций для своих виртуальных машин.

    Соглашения об уровне обслуживания для control plane управления Kubernetes также имеют некоторые удивительные различия. EKS остается единственным из трех провайдеров, которые берут за своих мастеров $ 0,10 / кластер / час. Эта сумма составит незначительную часть общей стоимости для всех, кроме самых маленьких кластеров, но обеспечивает то, что другие провайдеры не предлагают: SLA с финансовой ответственностью. Хотя возмещение штрафов за SLA почти никогда не сравнится с потерей потенциальной производительности или дохода, понесенного во время сбоя поставщика, предложение опубликованных штрафов может принести большую степень уверенности, в серьезности поставщика, надежности и времени безотказной работы.

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

    Хотя узлы и ноды, работающие в кластере Kubernetes, могут пережить перебои control plane и ее компонентах, даже кратковременные прерывания могут быть проблематичными для некоторых рабочих нагрузок. В зависимости от затронутых компонентов плоскости управления сбойные модули могут не переноситься по расписанию или клиенты могут не иметь возможности подключиться к API кластера для выполнения запросов или управления ресурсами в кластере. Если кластер etcd, который используется control plane для хранения текущего состояния кластера и его развернутых ресурсов, дает сбой, теряет кворум (при условии, что он был развернут как кластер высокой доступности) или испытывает серьезное повреждение или потерю данных, кластер Kubernetes может стать невосстановимым.

    Ограничения обслуживания

    Лимиты на аккаунт (AWS), подписку (AKS) или проект (GKE), если не указано иное.

    Лимиты, для которых клиент может запросить увеличение, отмечены звездочкой (*).

    EKS AKS GKE Кубернетес (по состоянию на v1.17)
    Максимально кластеров 100 / регион * 100 50 / зона + 50 региональных кластеров –
    Максимальное количество узлов в кластере Управляемые группы узлов: 1000 * (Формула: максимальное количество узлов на группу узлов * максимальное количество групп узлов на кластер)
    • 1000
    • 100 (наборы доступности VM)
    • 400 (сеть кубенет)
    • 800 (VM Scale Sets)
    • 5000
    • 1000 при использовании входного контроллера GKE
    		 5000
    Максимальное количество узлов на пул / группу узлов Группы управляемых узлов: 100 * 100 1000 –
    Максимальное количество пулов / групп узлов в кластере Группы управляемых узлов: 10 * 10 Не задокументировано –
    Максимальное количество pods на узел
    • Linux: Зависит от типа экземпляра узла : ((количество IP-адресов на Elastic Network Interface – 1) * количество ENI) + 2
    • Windows: количество IP-адресов на ENI – 1
    • 110 (сеть кубенет)
    • 30 (Azure CNI, по умолчанию)
    • 250 (Azure CNI, максимально., Настраивается во время создания кластера)
    		 110 100 (рекомендуемое значение, настраивается)

    Комментарии

    Хотя большинство из этих ограничений довольно просты, пара – нет.

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

    Между тем, в EKS планирование максимального количества модулей, которое может быть запланировано на узле Linux), требует некоторых исследований и расчетов. Кластеры EKS используют AWS VPC CNI для кластерной сети. Этот CNI размещает модули непосредственно в сети VPC с помощью ENI (Elastic Network Interfaces), виртуальных сетевых устройств, которые могут быть подключены к экземплярам EC2. Различные типы экземпляров EC2 поддерживают как разное количество ENI, так и разное количество IP-адресов (по одному на модуль) для каждого ENI.

    Чтобы определить, сколько модулей конкретного типа экземпляра EC2 может работать в кластере EKS, вы должны получить значения из этой таблицы и вставить их в следующую формулу: ((# IP-адресов на Elastic Network Interface – 1) * # ENI ) + 2

    Поэтому большой экземпляр EC2 c5.12x, который может поддерживать 8 ENI с 30 адресами IPv4 каждый, может вместить до ((30 – 1) * 8) + 2 = 234 модуля. Обратите внимание, что очень большие узлы с максимальным количеством запланированных модулей будут очень быстро поглощать блок CIDR / 16 IPv4 в кластере VPC.

    Пределы модулей для узлов Windows легче вычислить, но они также намного более ограничены в количестве модулей, поддерживаемых в EKS. Здесь используйте формулу # IP-адресов для ENI – 1. Тот же экземпляр c5.12xlarge, который может запустить до 234 модулей в узле Linux, может выполнять только 29 модулей в качестве узла Windows.

    Сетевая безопасностью

    EKS AKS GKE Kubernetes
    Сетевой плагин / CNI AWS VPC CNI Вариант между кубенетом или Azure CNI kubenet кубенет (по умолчанию; можно добавить CNI)
    Kubernetes RBAC Требуется
    • Включено по умолчанию
    • Должен быть включен во время создания кластера
    • Включено по умолчанию
    • Может быть включен в любое время
    		 –
    Сетевая политика Kubernetes
    • Не включен по умолчанию
    • Calico можно установить вручную в любое время
    • Не включен по умолчанию
    • Должен быть включен во время создания кластера
    • kubenet: Calico
    • Azure CNI: Calico или политика Azure
    • Не включен по умолчанию
    • Может быть включен в любое время
    • Calico
    • Не включен по умолчанию
    • CNI, реализующий API сетевой политики, может быть установлен вручную
    Поддержка PodSecurityPolicy Контроллер PSP установлен во всех кластерах с разрешающей политикой по умолчанию (v1.13 +) PSP может быть установлен в любое время ( предварительный просмотр ) PSP может быть установлен в любое время Контроллер доступа PSP должен быть включен как флаг kube-apiserver
    Частный или публичный IP-адрес для кластера API Kubernetes
    • Общедоступный по умолчанию
    • Частный адрес необязательно
    • Общедоступный по умолчанию
    • Частный адрес необязательно ( предварительный просмотр )
    • Общедоступный по умолчанию
    • Частный адрес необязательно
    		 –
    Публичные IP-адреса для узлов
    • Неуправляемые группы узлов: необязательно
    • Группы управляемых узлов: обязательно
    		 нет нет –
    Передача «от одного к другому», зашифрованная облаком нет нет нет нет
    Межсетевой экран для кластера Kubernetes API Опция белого списка CIDR Опция белого списка CIDR Опция белого списка CIDR –
    Доступная только для чтения корневая файловая система на узле Не поддерживается Не поддерживается
    • COS: да
    • Ubuntu: нет
    • Windows: нет
    		 Поддерживается

    Комментарии

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

    В целом, EKS делает все возможное, чтобы основные средства контроля безопасности Kubernetes были стандартными в каждом кластере. И наоборот, AKS усложняет управление безопасностью, требуя включения RBAC и сетевых политик во время создания кластера.

    Все три провайдера теперь развертывают с включенным по умолчанию RBAC Kubernetes, что является большой победой в части безопасности. EKS даже делает RBAC обязательным, как и для поддержки Pod Security Policy, которая, хотя и поддерживается двумя другими провайдерами, требует подписки для каждого кластера.

    С другой стороны, ни один из провайдеров в настоящее время не включает поддержку сетевой политики по умолчанию. EKS требует от клиента установки и управления обновлениями для Calico CNI самостоятельно. AKS предоставляет два варианта поддержки сетевой политики, в зависимости от типа сети кластера, но позволяет включить поддержку только во время создания кластера.

    Все три облака теперь предлагают несколько вариантов ограничения сетевого доступа к конечной точке API Kubernetes кластера. Даже с учетом RBAC в Kubernetes и включенного безопасного метода аутентификации для кластера, оставляя сервер API открытым для всего мира, он по-прежнему остается незащищенным от неизвестных или будущих уязвимостей, что было замечено совсем недавно в исправленной уязвимости Billion Laughs , которая создала возможность атаки отказа сервиса неаутентифицированными пользователями. Применение белого списка CIDR или предоставление API частного, внутреннего IP-адреса, а не публичного адреса, также защищает от таких сценариев, как взломанные учетные данные кластера.

    EKS представила группы управляемых узлов на re: Invent в декабре прошлого года. Хотя группы управляемых узлов удаляют значительную часть предыдущей работы, необходимой для создания и обслуживания кластера EKS, они имеют определенный недостаток для безопасности сети узлов: все узлы в группе управляемых узлов должны иметь общедоступный IP-адрес и должны иметь возможность отправлять трафик из VPC. Эффективное ограничение выходного трафика от узлов становится более сложным. Хотя внешний доступ к этим общедоступным адресам может быть защищен с помощью надлежащих правил групп безопасности и сетевых ACL-списков, они по-прежнему представляют серьезный риск, если клиент неправильно настраивает или не ограничивает сетевые элементы управления VPC кластера. Этот риск можно несколько смягчить, разместив узлы только в частных подсетях.

    Контейнерные образы сервисов

    EKS AKS GKE
    Служба репозитория образов ECR (реестр контейнеров Elastic) ACR (реестр контейнеров Azure) GCR (Реестр контейнеров Google)
    Поддерживаемые форматы
    • Docker Image Manifest V2, схема 1
    • Docker Image Manifest V2, схема 2
    • Open Container Initiative (OCI)
    • Docker Image Manifest V2, схема 1
    • Docker Image Manifest V2, схема 2
    • Open Container Initiative (OCI)
    • Docker Image Manifest V2, схема 1
    • Docker Image Manifest V2, схема 2
    • Open Container Initiative (OCI)
    Безопасность доступа
    • Разрешения, управляемые AWS IAM
    • Разрешения могут применяться на уровне хранилища
    • Конечная точка сети по умолчанию общедоступна
    • Конечная точка сети может быть ограничена определенными VPC
    • Разрешения, управляемые Azure RBAC
    • Может применяться на уровне хранилища ( предварительный просмотр )
    • Конечная точка сети по умолчанию общедоступна
    • Конечная точка сети может быть ограничена определенными виртуальными сетями ( предварительный просмотр )
    • Разрешения, управляемые GCP IAM
    • Разрешения могут применяться только на уровне реестра
    • Конечная точка сети по умолчанию общедоступна
    • Доступ к сети для реестров GCR может быть ограничен конкретными VPC с периметрами обслуживания.
    Место хранения S3 buckets Не задокументировано GCS buckets
    Безопасность хранения
    • Доступ к сегменту можно защитить с помощью разрешений S3 или AWS IAM.
    • Доступ к конечной точке базовой сети может быть ограничен определенными VPC
    		 Не документировано (может не применяться)
    • Доступ к сегментам может быть защищен через GCP IAM, но некоторые разрешения применяются глобально ко всем сегментам в проекте.
    • ACL могут использоваться для управления разрешениями для отдельных объектов сегмента. ( GCR не учитывает ACL объекта GCS, только разрешения bucket. )
    • Доступ к сети может быть ограничен с использованием периметра обслуживания
    Поддерживает подпись образа нет да нет
    Поддерживает неизменяемые теги образов да нет нет
    Сервис сканирования образов Да ; Только пакеты ОС Да ( превью ); неясно, включены ли библиотеки языка приложений во время выполнения Да ; Только пакеты ОС
    Реестр SLA 99,9%; финансовая ответственность 99,9%; финансовая ответственность Неизвестно

    Комментарии

    Все три облачных провайдера предлагают аналогичные услуги по регистрации образов контейнеров. Добавление в ACR поддержки подписи образов позволяет пользователям устанавливать и подтверждать подлинность и целостность своих образов. Поддержка ECR для неизменяемых тегов образов помогает пользователям полагать, что использование одного и того же тега image: приведет к развертыванию одной и той же сборки образа контейнера каждый раз.

    Все три службы реестра также допускают некоторую степень контроля доступа. Однако степень контроля варьируется. ECR и ACR поддерживают ограниченный контроль доступа к уровню хранилища, который не поддерживается GCR. Кроме того, поскольку управление доступом к реестру GCR напрямую зависит от разрешений для bucket Google Cloud Storage, поддерживающей этот реестр, ограничение доступа к корзине хранения с помощью периметра службы может нарушить доступ к bucket GCS в других проектах GCP , в том числе с другой стороны.

    Примечания о данных и источниках

    Информация в этом посте должна рассматриваться снимком этих сервисов Kubernetes на момент публикации. В частности, поддерживаемые версии Kubernetes будут регулярно меняться. Функции, которые в настоящее время находятся в режиме предварительного просмотра (терминология Azure) или бета-версии (терминология GCP), помечены как таковые и могут измениться, прежде чем станут общедоступными. В настоящее время AWS не имеет соответствующих функций предварительного просмотра, перечисленных в их документации EKS.

    Все данные в таблицах взяты из официальной онлайн-документации поставщика (kubernetes.io в случае Kubernetes с открытым исходным кодом), которая в некоторых случаях дополняется проверкой запущенных кластеров и запросами API служб. Часть этой информации, особенно для поддерживаемых версий Kubernetes, может относиться к регионам США; доступность может отличаться в других регионах. Значения для Kubernetes с открытым исходным кодом опускаются, если они либо относятся к управляемой службе, либо зависят от того, как и где развернут самоуправляемый кластер.

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

    Мы также не рассматриваем различия в производительности между провайдерами. Многие переменные вступают в игру для сравнительного анализа.

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

  • Бесплатное решение для аварийного восстановления с Hyper-V Replica 2019

    Бесплатное решение для аварийного восстановления с Hyper-V Replica 2019

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

    Стратегия аварийного восстановления является важной частью  ИТ-среды. Независимо от размера вашей компании, если ваш повседневный бизнес опирается на ИТ-инфраструктуру, например, приложение кассы для продажи ваших продуктов и предоставления клиенту билетов, вам нужен план аварийного восстановления. Планы аварийного восстановления состоят из нескольких этапов, таких как приложение, подключение или аппаратный сбой. В этом посте мы подробнее рассмотрим, как Hyper-V Replica может помочь в устранении сбоев оборудования.

    Требования 

    Реплика Hyper-V является неотъемлемой частью роли Hyper-V и доступна без дополнительной оплаты. Если вы используете бесплатное Hyper-V Server Core для виртуализации своей среды, вы можете полностью покрыть часть своей стратегии аварийного восстановления с помощью Hyper-V Replica, что очень здорово, не правда ли? Особых требований нет, и все, что вам нужно, это две простые вещи:

    • Прочная связь между серверами
    • Хранилище с приличными IOPS

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

    • Количество виртуальных машин, которые вы собираетесь скопировать
    • Как часто вам нужно синхронизировать данные. Есть три варианта: 30 секунд, 5 или 15 минут

    Настройка сервера реплики 

    Настройка серверов реплики – очень простая задача. В диспетчере Hyper-V щелкните правой кнопкой мыши на свой сервер Hyper-V и выберите «Параметры Hyper-V». В разделе «Настройка репликации» установите флажок «Включить этот компьютер в качестве сервера реплики». Вы можете выбрать два метода аутентификации для входящего трафика: Kerberos или HTTPS. В нашем случае, так как оба сервера Hyper-V подключены к домену, я использую Kerberos. Если вам требуется зашифрованный трафик или ваши серверы не являются членами домена, вам следует выбрать HTTPS-аутентификацию. Для HTTPS требуется действительный сертификат, самоподписанный или выданный кем-либо.

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

    Настроить брандмауэр

    Есть два правила брандмауэра, созданные по умолчанию:

    • HTTPS-слушатель реплики Hyper-V (TCP-In) для трафика Kerberos
    • Прослушиватель HTTPS реплики Hyper-V (TCP-In) для трафика HTTPS

    Если вы оставили порты по умолчанию в конфигурации репликации, просто включите нужное вам правило. В противном случае вам нужно обновить порт в правиле.

    Включение репликации 

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

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

    Далее вы можете выбрать виртуальные диски для репликации. Обычно это все диски.

    На следующем шаге выберите, как часто вы хотите копировать данные. Как упоминалось ранее, у вас есть три варианта.

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

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

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

    Это говорит о том, что сетевые адаптеры не подключены ни к одной сети. Это связано с тем, что на сервере-реплике отсутствует виртуальный коммутатор с таким же именем. Если вы создадите виртуальный коммутатор с тем же именем, которое виртуальная машина использует на основном сервере, он будет автоматически подключен к серверу реплики.

    Выполнение аварийного переключения

    Когда репликация включена и начальная передача завершена, мы можем выполнить операцию восстановления после отказа. Есть два варианта:

    • Test Failover – используется для проверки возможности успешного запуска реплики ВМ. Эта опция создает дубликат реплики виртуальной машины и удаляется после завершения теста.
    • Failover – используется в случае возникновения проблем с основным сервером Hyper-V.

    Чтобы выполнить отработку отказа, просто щелкните правой кнопкой мыши виртуальную машину реплики и выберите Failover или Test Failover.

    Появится подтверждающее сообщение с предупреждением о том, что не следует выполнять отработку отказа, если не произошел сбой основной ВМ. Если вы настроили репликацию, чтобы иметь больше точек восстановления, вы можете переключиться на любую из них. Нажмите Fail Over, чтобы завершить процесс.

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

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

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

    Заключение

    Hyper-V Replica – это отличная бесплатная функция DR, которая проста в настройке и использовании. В случае, если вы хотите иметь реплику ВМ на третьем сервере, это также возможно с помощью функции расширенной репликации. Для получения дополнительной информации о Hyper-V Replica вы можете обратиться на веб-сайт Microsoft docs. Там вы найдете статью, написанную для Windows Server 2016, но ее также можно применить к Windows Server 2019.