Я работаю в центре киберзащиты DataLine и в числе прочего занимаюсь межсетевыми экранами нового поколения (NGFW): тестирую новые решения, внедряю, настраиваю, слежу за работоспособностью. 

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

С этой мыслью мы запустили тесты производительности отечественного UTM UserGate в интересном контексте: мы подняли версию UserGate на программно-аппаратном комплексе от зарубежного вендора NGFW. В статье поделюсь сценариями тестирования и покажу результаты на одном популярном устройстве. При желании такие же тесты можно прогнать на любом другом оборудовании.

Многие наши клиенты используют для сетевой защиты популярные межсетевые экраны нового поколения (NGFW). С их помощью компании анализируют входящий и исходящий трафик, предотвращают вторжения, строят VPN-тоннели до конечных устройств и так далее. Кто-то приобретает аппаратные или виртуальные NGFW и администрирует их сам, кто-то арендует у нас ресурсы и получает NGFW как сервис. 

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

В статье на примере отечественного UTM UserGate покажу варианты страховки: от временного переключения на отечественный файрвол до полной замены NGFW. 

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

В статье разберем, какими способами мы предлагаем нашим клиентам минимизировать риски использования Office 365. Сейчас этот офисный пакет входит в состав подписки Microsoft 365 и включает Word, Excel, PowerPoint, Outlook/Exchange, OneDrive, Teams и еще несколько приложений.

Привет, Хабр! Меня зовут Николай, я работаю менеджером по продукту в ИТ.  В прошлом году я перешел из компании поменьше в DataLine, где как раз начались интенсивные изменения в управлении продуктами. 

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

В предыдущей части я рассказывал, почему для ИБ важна валидация маршрутов в ВGP и как каждый клиент сервис-провайдера может обезопасить протоколы маршрутизации с помощью RPKI. 

Но если у вас своя АС с несколькими пирингами, как это бывает у многих банков или ИТ-компаний, то лучшим решением будет внедрить свою валидацию и фильтрацию маршрутов на основе RPKI. И в этом случае прошлой весной вас (и нас) ждал неприятный сюрприз. Широко используемый RPKI-RTR-сервер от RIPE успел получить статус deprecated ☹. Прекратилась разработка и дальнейшая поддержка продукта, с последующим удалением из официального репозитория.

Так что во второй короткой части расскажу, как мы решали проблему с заменой решения и внедряли RPKI на нашем сетевом оборудовании. Покажу на примере Cisco, для которого инструкции от RIPE почему-то нет.

В крупных компаниях с развитой ИТ-инфраструктурой нередко есть отдельная роль DBA — администратора или архитектора баз данных. Таким компаниям бывает выгоднее держать базы данных у себя и администрировать ресурсы своими силами.  

В компаниях поменьше случается, что зона компетенций DBA остается “ничьей землей”: в лучшем случае эту роль могут отдать в нагрузку кому-то из смежных специалистов. В дальнейшем это грозит проблемами, если инфраструктура резко вырастет или усложнится. И тут как раз поможет внешний DBA: независимый консультант по базам данных или специалист в рамках облачного сервиса управляемых БД, если компании нужны еще и ресурсы в облаке. 

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

Итак, вы наконец-то стали счастливым обладателем k8s-кластера: получили его в наследство, в подарок на Новый год, заказали в DataLine) и т. п. У новых клиентов и даже у опытных пользователей часто возникает вопрос, как оценить кластер и проверить его работоспособность? 

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

Привет, Хабр! Меня зовут Даниил Воложинок, я инженер в группе виртуализации. Представьте себе ситуацию. У вас есть сервер с комплексом приложений и настроек, который несколько лет обслуживает админ — ”золотые руки”. Однажды “золотой” админ увольняется или уходит на длительный больничный. На его смену приходит новый и выясняет, что разобраться в наследстве невозможно: большинство сведений его предшественник держал в голове. 

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

В статье поделюсь наработанным списком для документирования сервера, который мы собрали внутри компании и теперь высылаем в качестве рекомендации и крупным клиентам DataLine, и небольшим клиентам Cloudlite. Ресурсы Cloudlite нередко используются для стартапов и pet-проектов. А когда стартап вдруг резко взлетает, становится некогда думать о документировании. Так что привычка сразу все фиксировать помогает нашим клиентам не запутаться. 

В ноябре Nature опубликовал работу учёных Женевского университета (UNIGE) и канадского Университета Макгилла, которые решили заменить привычную систему PIN-кодов на более безопасную. В поисках сверхнадежной аутентификации исследователи предложили пересмотреть фактор владения и опираться на метод математического доказательства с нулевым разглашением в связке со специальной теорией относительности. 

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

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

- какие есть варианты для связи независимых дата-центров по России;

- какие трудности появляются на больших расстояниях и как их преодолеть;

- где между телеком-операторами возникают серые зоны, за которые никто не отвечает.

Размещение ИТ-инфраструктуры на двух и более площадках решает разные задачи: помогает быстро расширить ресурсы или стать ближе к конечному потребителю в случае размещения контента в разных CDN-зонах. Но особенно часто такое распределение систем используется для георезервирования: когда при выходе из строя одной площадки вторая находится вне зоны аварии и берет на себя критически важные нагрузки.

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

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

- в первой части покажем сценарии георезервирования и варианты связности в рамках одной сети дата-центров в одном городе; 

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

Любое отключение питания в стойке — это инцидент, который инженер дата-центра должен решить в минимальные сроки. Чаще всего критически важное оборудование в ЦОДе запитано от двух лучей, и после сбоя одного луча устройства нормально работают от второго. Но бывают банальные ошибки подключения и нестандартные случаи, из-за которых "падает" вся стойка.

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

Сегодня расскажем, как учесть этот опыт и снизить вероятность "падения" серверной стойки.

Привет! На связи Алексей Волков, и я опять про «Сервисдеск» в DataLine. На сей раз покажу его мобильную реинкарнацию.

Три года назад мы создали десктопную систему для работы с заявками в техподдержку и дали ей говорящее название «Сервисдеск». Сейчас это решение работает во всех дата-центрах объединенной команды DataLine и «Ростелеком-ЦОД» и охватывает около 700 ежедневно активных пользователей. Мобильная версия «Сервисдеска» была лишь вопросом времени: доступность любых внутренних систем с портативных устройств сразу ускоряет цикл обработки запросов. А для клиентских заявок в техподдержку это особенно важно.

Под катом — краткая предыстория разработки мобильного клиента для «Сервисдеска» и демонстрация сценариев его работы.

Привет, Хабр! Меня зовут Антон Турсунов, я руковожу центром подготовки дежурного персонала ЦОД и уже давно считаю день знаний своим праздником. До этого я был старшим инженером службы технической поддержки на площадке OST и занимался обучением дежурных дата-центра: помогал освоить особенности оборудования и ПО, рассказывал про специфику работы с клиентскими запросами и другие азы профессии инженера. 

В прошлом году наша сеть дата-центров расширилась: команды «Ростелеком-ЦОД» и DataLine объединились, да еще и начали вместе строить новые ЦОДы. К московским площадкам добавились региональные: в Удомле, Санкт-Петербурге, Екатеринбурге, Новосибирске. Стало важно выстроить единую систему обучения дежурных, при этом сохранить гибкость и учесть особенности подготовки на местах.

Расскажу, как мы решаем эту задачу в центре подготовки инженеров ЦОД, как и почему сделали его распределенным, и какие изменения произошли в системе обучения в компании.

Hystax — подходящее решение для миграции, если нужно перенести ВМ с Linux или Windows между разными платформами: VMware, OpenStack, AWS и так далее. C его помощью можно переехать на любую из этих платформ даже с bare-metal. Мы уже не раз использовали Hystax для переезда наших клиентов с VMware в OpenStack. Также Hystax можно использовать для послеаварийного восстановления (DR).

Несколько месяцев назад один из клиентов обратился к нам с задачей переезда с OpenStack на VMware. Потом клиент передумал, но мы все равно провели пару тестов с миграцией и аварийным восстановлением на VMware. Выяснилось, что без знания особенностей Hystax можно внезапно закопаться в ручных настройках сети. Для DR это фатально, так как ручная настройка сразу увеличивает RTO. Но и для миграции настройка вручную не очень хороша. Без опыта с Hystax можно неверно спланировать работу, не уложиться в технологическое окно и нарушить сроки переезда.

В статье расскажу, где настройки могут не подняться автоматически и как с этим бороться. Показывать буду на версии Hystax DR 3.7.1701.

Ливни, грозы, шквалистый ветер и рекордная жара — этим летом много поводов обсудить погоду. В дата-центрах это не только тема для смол-тока. Природные аномалии и катаклизмы могут сильно повлиять на работу оборудования, если не подумать обо всех рисках заранее. Мы с @rbekrenev обобщили наш опыт и рассказываем, как инженеры дата-центров готовятся ко встрече со стихией.

Vault от HashiСorp — довольно известное open-source-решение для хранения секретов и неплохая альтернатива реализации секретов в Kubernetes. Vault использует свой сайдкар-контейнер на каждом поде, который получает секреты из хранилища и доставляет их в под или же реализует доступ к секретам через csi-драйвер.

Но как быть, если необходимо положить секреты из Vault в секреты Kubernetes? Например, мы хотим хранить и обновлять свой tls-сертификат для ингресса из Vault. Или мы решили использовать gitops и хотим, чтобы в репозитории безопасно хранилось все описание инфраструктуры, в том числе и секретов Kubernetes?

Разберем этот сценарий на практике и реализуем его с помощью vault-secrets-operator.

В этом году мы обновили сервис облачного мониторинга и представили клиентам более удобное и понятное решение для отслеживания статуса их ИТ-инфраструктуры. Сервис вырос из нашей системы мониторинга дата-центра, где мы отслеживаем сотни тысяч метрик в работе оборудования. Какие-то из них очевидные, а какие-то вызывают у клиентов реакцию: “А что, так можно было?!”

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

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

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

Где кончается базовая ИБ-гигиена для небольшого бизнеса и начинается киберзащита для продвинутых? Центр интернет-безопасности (CIS) обновил рекомендации по внедрению ИБ для компаний разного масштаба в свежем гайде CIS Controls 8.

Предыдущие рекомендации CIS Controls 7.1 вышли в 2019 году. В версии 7.1 сделали упор на список практик для внедрения: что именно бизнес должен сделать для защиты. В восьмой версии этот подход сохранили и учли угрозы, связанные с “пандемийными” изменениями ИТ-ландшафта: массовой работой из дома, ростом мобильных пользователей, миграцией в облака. Например, появился отдельный раздел ― контроль безопасности сервис-провайдера (мимо такого пройти не cмогли). 

Мы изучили рекомендации CIS для разных бизнесов и выделили самое интересное.