О необходимости выполнения резервного копирования для любых важных данных, будь то файлы, образ ОС или базы данных, написано множество статей. Поэтому убеждать читателя в необходимости бэкапить СУБД MySQL я не буду. Напомню лишь, что помимо бэкапа необходимо регулярно проверять резервные копии на возможность восстановления.

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

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

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

Про Kubernetes написано огромное количество статей. Установка, настройка, мониторинг и безопасность все эти аспекты рассматриваются достаточно подробно. При этом, отдельным пунктом идет создание и настройка контейнеров. И если для решения глобальных задач  администрирования нужен Kubernetes уровня продакшен, то для работы с контейнерами промышленные мощности как правило не требуются, по крайней мере до этапа нагрузочного тестирования. Например, программисту нужно создать контейнер со своим приложением. Для этого ему будет вполне достаточно Minikube который позволит работать с контейнерами локально.

В этой статье мы рассмотрим использование minikube для работы с контейнерами. Поговорим о том, чем Minikube отличается от «большого» Kubernetes. Но начнем мы с процесса установки Minikube.

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

В этой статье мы будем говорить о том, как устроено логирование событий в ОС Linux. В качестве примера будет рассматриваться Ubuntu Linux 22.04, однако в других дистрибутивах основные элементы будут сходными.   

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

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

Представленный в статье материал предполагает знакомство читателя с основами объектно-ориентированного программирования.

В сегодняшней статье мы поговорим об устройстве дисковой подсистемы в ОС Linux. Конечно, многие скажут, что на эту тему написано уже множество статей и все и так прекрасно знают, как устроен Линукс и в том числе, как он работает с дисками. Однако, как показывает практика, даже многие администраторы при работе с дисковой подсистемой ограничиваются только начальным разбиением диска при установке операционки. Да и то, с параметрами по умолчанию. Так что я предлагаю подробнее рассмотреть такие вопросы дисковой подсистемы, как: работу с правилами правила системы udev, инструменты для работы с блочными устройствами и планировщики системы ввода/вывода.

MySQL на сегодняшний день является одной из наиболее распространенных в мире. Достаточно сказать, что по рейтингам 2021 года данная СУБД лишь немного уступала Oracle.

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

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

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

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

Сейчас трудно себе представить «боевую» инсталляцию любой серьезной СУБД в виде единственного инстанса. Конечно, некоторые приложения требуют для своей работы использование локальных баз данных, но если мы говорим о сетевом многопользовательском режиме работы, то здесь использование только одной инсталляции это очень плохая идея.

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

Да и исправный бэкап есть не всегда, но об этом мы уже говорили в предыдущей статье.

В предыдущих статьях (Часть 1, Часть 2) мы поговорили о том, как может действовать Внешний нарушитель (пентестер за пределами организации) и Гость (пентестер  имеет только доступ в сеть) при проведении пентеста. Также начали рассматривать действия Внутреннего нарушителя (пентестер имеет доступ с правами доменного пользователя) в контексте анализа трафика. Сегодня мы продолжим рассмотрение векторов атак для данной роли и также поговорим о том как можно использовать социальную инженерию при пентесте и совмещать ее с техническими методами.

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

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

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

О тестировании на проникновение написано уже немало книг и статей. Эта тема становится все актуальнее с каждым новым инцидентом ИБ. Злоумышленники проникают в сети различных организаций с целью прямого хищения денег с счетов (банки, финансовые организации), атак на отказ в обслуживании (предприятия критической инфраструктуры), хищения персональных данных и других вредоносных действий. Системы информационной безопасности большинства организаций не способны в полной мере защитить от действий квалифицированных злоумышленников. Причин этому несколько. В России традиционным драйвером рынка ИБ являются требования регуляторов (ФЗ 152, ФЗ 187 и т.д.) и при построении системы защиты прежде всего стремятся выполнить требования приказов ФСТЭК, ФСБ, ЦБ и т.д. Проведя категорирование, построив модель угроз, написав ОРД, спроектировав и внедрив систему защиты заказчик считает что он теперь защищен. Хотя обычно этого недостаточно.

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

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

 На сегодняшний день существует большое количество различных систем управления базами данных - СУБД, от коммерческих до открытых, от реляционных до новомодных NoSQL и аналогичных.

Одним из лидеров направления СУБД является PostgreSQL и ее различные ответвления, о некоторых из которых мы рассмотрим подробнее.

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

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

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

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

В предыдущей статье мы рассмотрели основы языка HCL, используемого Terraform для описания требуемых конфигураций. Также мы подготовили небольшое описание для создания экземпляра EC2 в AWS. Однако, в представленном описании у на присутствуют только основные параметры, необходимые для создания узла, но отсутствуют, к примеру параметры для настройки сети.

Для полноценной автоматизации нам было бы неплохо прописать все необходимые для работы сетевые интерфейсы. Для этого объявим две переменные net_primary и net_ad для двух сетевых интерфейсов. Если вам не требуется второй интерфейс, net_ad можно не указывать, однако в большинстве случаев для серверов требуется скорее большее количество сетевых портов.

Управление распределенной архитектурой требует значительных трудозатрат и финансовых вложений. Для автоматизации этого процесса можно использовать различные самописные скрипты, но лучше воспользоваться готовыми решениями с открытым исходным кодом. Одним из наиболее известных решений для автоматизации управления инфраструктурой является Terraform. Это Open source решение для управления IaC от компании Hashicorp, разработанное в 2014 году. Решение придерживается декларативного стиля управления инфраструктурой, то есть, вы описываете в конфигурационном файле  финальное состояние инфраструктуры, а Terraform приводит её к этому состоянию. В качестве примера можно привести автоматическое развертывание пула виртуальных машин, например для проведения обучения работе с каким-либо ПО.

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

Для того, чтобы описание работы с Terraform не было “сферическим конем в вакууме”, мы в качестве наглядного примера, рассмотрим практический пример создания экземпляра EC2 в AWS.

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

В этой обзорной статье мы рассмотрим основные решения для реализации IaC и поговорим об их достоинствах и недостатках.

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

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