Не можете разобраться, что происходит в сетевой инфраструктуре? Создание Access Control List (ACL) давно стало рутиной, но по-прежнему отнимает очень много времени? Приходится управлять несколькими межсетевыми экранами разных вендоров одновременно? Скоро придет аудитор, чтобы проверить, насколько написанные вами правила доступа соответствуют требованиям регулятора или отраслевому стандарту? Если вы узнали себя хоть в одном вопросе, этот текст для вас.
В общем, добро пожаловать под кат все ищущие унификации в анализе и контроле настроек межсетевых экранов (МСЭ) и сетевых устройств.
В одном проекте мы строили новую ИТ-инфраструктуру и консолидировали на нее базы данных Oracle. Базы были разных объемов и степени критичности (вплоть до Business Critical). Казалось бы, штатная задача. Но в ней таилась одна особенность, о которую мы поломали немало копий, — развертывание на VMware кластера Veritas HA.
Мы запускаем второй сезон вебинаров DevSecOps. В первом — мы говорили «много и обо всем». Теперь рассмотрим более локальные задачи: от мониторинга k8s и организации конвейера GitOps до управления «секретами» и резервного копирования в Kubernetes.
Все задачи, которые мы рассмотрим на вебинарах, из реальных проектов и не привязаны к решениям конкретных вендоров. О каждой задаче мы будем говорить с точки зрения ИТ, разработки и безопасности. Узкие специалисты в области ИБ, ИТ и разработки смогут погрузиться в свои области и поймут смежные участки, а ИТ-менеджмент сможет посмотреть на весь процесс сверху.
Подробнее о вебинарах и ссылки на регистрацию под катом.
Как выбрать ИБП для дата-центра? Ответить на этот вопрос нам помогли самые популярные запросы в Google и «Яндексе», а также эксперты: Сергей Батраков, пресейл-инженер центра сетевых решений компании «Инфосистемы Джет», и менеджер по продукции Digital Energy из Huawei Алексей Емельянов. Их ответы на семь самых популярных Google- и «Яндекс»-вопросов по теме — под катом. Бонус: рассказ о том, как электрик умудрился вывести из строя батарейные модули ИБП, перепутав плюс и минус.
Автор: Антон Головко, специалист по машинному обучению «Инфосистемы Джет»
Человечество с переменным успехом занимается плавкой стали больше 3,5 тысяч лет. Казалось бы, зачем в металлургии вычислительные мощности и инфраструктура? Модели машинного обучения и искусственный интеллект лучше оставить торговым сетям и банкам для прогнозирования потребностей клиентов. А опытные сталевары всегда могли выплавить качественную сталь без ML. Зная, какую марку нужно получить на выходе, специалист самостоятельно определяет, какие добавки и в каком объеме необходимо использовать. И зачем тогда Machine Learning?
Работа на коротких проектах похожа на курортный роман. Встретились, события закрутились, на пике эмоций помахали друг другу рукой. Другое дело, если проект длится годами. Тогда совместная проектная команда проживает запал на старте, а потом проходит через несколько кризисов как настоящая семейная пара. В таких историях менеджеру проекта не получится только отслеживать «сделали/не сделали». С особым рвением ему нужно следить за тем, чтобы мотивация команды не сдувалась, а еще поддерживать репутацию коллег в глазах клиента. Как? Делюсь своим опытом.
Маркетинговые описания облаков обещают много благ: эти технологии оптимизируют расходы на ИТ, трансформируют инфраструктуру, делают ее более адаптивной. И это — чистая правда. Вот только на практике получить преимущества от облачных технологий в «кровавом Enterprise» оказывается непросто. Почему? Крупные компании ставят две основные задачи перед своей ИТ-инфраструктурой: защита критически важных данных и обеспечение высокой производительности. И чаще всего мечты об облаках налетают на них и разбиваются вдребезги. Так как же подружить облака и строгие стандарты крупных корпораций?
Внимание! Данная статья носит исключительно информационный характер и предназначена для образовательных целей.
Представим себе типичный внутренний пентест. Вы приезжаете к заказчику, подключаетесь к Ethernet-розетке.Вы заранее предупредили о своём приезде, попросили себе рабочее место с Ethernet-розеткой и договорились отключить 802.1x. В итоге нашли тонну критических уязвимостей и в деталях расписали, как всё плохо исправить. Вы выдали красивый отчёт, оценили риски и составили рекомендации. Заказчик смотрит в отчет, хмурит брови и выдает непробиваемый довод: просто я отключил 802.1х. Добились бы вы таких же результатов без доступов к сети?
В этом посте я продемонстрирую, как легко можно обойти 802.1x на внутреннем пентесте. За редкими исключениями, но их мы тоже обсудим.