Продолжаем делиться с вами крутыми материалами по теме информационной безопасности, которые обнаружили в сети. И не могли обойти вниманием достойный англоязычный подкаст Darknetdiaries. Один из его эпизодов – это разговор двух опытных пентестеров (Гари и Джастина).
Они рассказывают историю о том, чем для них обернулся однажды аудит безопасности. Пентестеры взломали входы в помещения и ИТ-инфраструктуру суда, а всего несколько часов спустя оказались там же, но как подсудимые. Доказать невиновность им удалось только месяцы спустя, так что историю можно вполне считать драматичной, если бы не чувство юмора рассказчиков.
Делимся находкой и для удобства пересказываем историю от третьего лица. Пентестеры раскрывают лишь малую часть приемов, которые используют в работе, чтобы не дарить информацию тем, кто решит воспользоваться ею в преступных целях.
Оригинал для желающих тут – и в аудио, и в текстовом формате.
Многие знают и используют Terraform в повседневной работе, но для него до сих пор не сформировались лучшие практики. Каждой команде приходится изобретать свои подходы, методы.
Ваша инфраструктура почти наверняка начинается просто: несколько ресурсов + несколько разработчиков. Со временем она растёт во всевозможные стороны. Вы находите способы сгруппировать ресурсы в Terraform-модули, организовать код по папкам, и что здесь вообще может пойти не так? (известные последние слова)
Проходит время, и вы чувствуете, что ваша инфраструктура — это ваш новый питомец, но почему? Вас беспокоят необъяснимые изменения в инфраструктуре, вы боитесь прикасаться к инфраструктуре и коду — в итоге вы задерживаете новый функционал или снижаете качество…
После трёх лет управления на Github коллекцией community-модулей Terraform для AWS и долгосрочном поддержании Terraform в продакшене, Антон Бабенко готов поделиться своим опытом: как писать TF-модули, чтобы не было больно в будущем.
К концу доклада участники будут лучше знакомы с принципами управления ресурсами в Terraform, лучшими практиками, связанными с модулями в Terraform, и некоторыми принципами непрерывной интеграции, связанными с управлением инфраструктурой.
Zabbix Summit – мероприятие, на котором можно узнать о выдающихся случаях использования Zabbix и ознакомиться с техническими решениями, представленными мировыми ИТ экспертами. Девять лет подряд мы организовывали мероприятия, собирающие сотни посетителей из десятков стран. В этом году мы принимаем новые правила и переходим на онлайн-формат.
Я давно собирался настроить мониторинг службы DFS Replication на нашем Zabbix, но готовых шаблонов в сети не нашел. Попалось несколько заброшенных проектов тут и тут, но первый автор так и не довел до конца, а во втором не работала ссылка для скачивания шаблона. К тому же, оба ограничивались лишь мониторингом бэклогов, хотя по факту метрик намного больше. Поэтому я решил сделать свой велосипед с круглым рулем и турбинами шаблон с дискавери и скриптами. Начал уже давно, но довести дело до конца всё руки не доходили. Как говорится, нет худа без добра: на удаленке в самоизоляции наконец доделал. Работы было проделано много, но я не жадный, поэтому делюсь.
Меня зовут Никита, я системный инженер в компании SEMrush. И в этой статье я расскажу вам, что такое Immutable Infrastructure, какие у этого подхода есть преимущества и недостатки и как мы его используем в компании.
Если вы ни разу не слышали такое словосочетание, то усаживайтесь поудобнее, будет интересно.
Immutable Infrastructure — подход к созданию неизменяемой инфраструктуры. Идея его не нова в мире, хоть и не слишком распространена. Мы начали его использовать, когда поняли, что не все можно запустить в Kubernetes, и нам нужны виртуальные машины.
Это подход о виртуалках, к которым надо относиться как к "пакетам" или контейнерам. Образ виртуальной машины, приложение и его окружение — неделимое целое. Деплой новой версии приложения подразумевает создание нового образа виртуальной машины, развертывание из него виртуалки и введение машины в строй на замену "старых" виртуалок. В общем, это практически попытка сделать контейнер из виртуалки.
Ниже мы рассмотрим преимущества и недостатки этого подхода, но прежде я хотел бы вставить небольшую оговорку.
В сегодняшней статье мы поставим последний кусочек пазла на его место. Мы собираемся представить вам часть нашего SOC, касающуюся управления делами. Мы использовали две технологии с открытым исходным кодом — TheHive и Cortex.
TheHive будет использоваться в качестве платформы управления оповещениями для нашего проекта, которая может управлять оповещениями об инцидентах от создания до закрытия. Между тем, Cortex — это дополнительный программный продукт от той же команды, что и TheHive, который дополняет его функцией обогащения данных с помощью своих «анализаторов» и «респондентов».