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 выполнять все настройки вручную. Если в прежние времена многие задачи по развертыванию и обслуживанию проще и быстрее было выполнить самому, то сейчас средства автоматизации позволяют существенно сэкономить время при работе с большим количеством элементов инфраструктуры.

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

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

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

Напомню основные моменты относительно учетных записей в Линукс: есть суперпользователь root (id=0), который может все и есть все остальные учетные записи (id от 500 или 1000), которые имеют ряд ограничений и по идее не могут нанести большого вреда системе.

Но на практике возможны различные ситуации, когда обычному пользователю необходимы административные права. Например, обычный пользователь не может прочитать файл с хэшами паролей /etc/shadow, но он может изменить свой собственный пароль с помощью команды passwd. Очевидно, что для внесения изменений в защищенный файл команда должна выполняться с правами суперпользователя. И таких примеров может быть довольно много.

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

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

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

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

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

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

Технологии контейнеризации в последние годы получили широкое распространение и наиболее известным решением по управлению контейнерами по праву считается Kubernetes, или, сокращенно, K8s. Kubernetes это система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими. Данная система построена на базе программного обеспечения с открытым исходным кодом. Изначально решение разрабатывалось специалистами Google, начиная с 2014 года и предназначалось для решения внутренних задач корпорации. Однако, впоследствии Kubernetes стал решением Open-Source и получили широкое распространение по всему миру.

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

В целом, K8s можно назвать стандартом для современных DevOps-сред в организациях различного уровня. Например, Kubernetes используется в таких облачных сервисах, как: AWS, Microsoft Azure или Google Cloud.

Часть 2. Как искать ошибки в чужом коде

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

Часть 1. Как писать свой код без ошибок

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

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

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