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

В этой статье мы продолжим рассмотрение процесса построения системы защиты персональных данных. В предыдущей статье мы остановились на определении Уровня защищенности персональных данных.

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

В этой статье мы продолжим разворачивать и настраивать LDAP под Linux. В первой части мы выполнили базовую установку slapd, развернули домен domain.com, и добавили записи в каталог.

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

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

Глобальный каталог LDAP стал неотъемлемой частью современной ИТ инфраструктуры любой крупной организации. Сама технология каталога LDAP у большинства плотно ассоциируется с Active Directory от Майкрософт. Однако сейчас все больше организаций пытаются уйти от решений данного вендора и перейти на софт с открытым исходным кодом.

В этой статье мы поговорим о том, из каких компонентов состоит LDAP и выполним некоторые основные настройки под Ubuntu. Но сначала немного теории о том, что эта технология из себя представляет.

Современное программное обеспечение имеет довольно сложную структуру. Разработку, как правило, ведет целая команда, в которую входят как непосредственно программисты, так и специалисты по качеству кода, тестировщики и т.д. В результате, важную роль организация работы всех этих специалистов как единой команды. И перед началом разработки нам, прежде всего необходимо перевести требования заказчика, о есть бизнеса на технический язык. То есть, нам необходимо понять, какие компоненты ИТ систем участвуют в каких бизнес процессах и затем, на основании этих требований уже готовить техническое задание на разработку программного продукта. И хотя, за анализ бизнес процессов в команде как правило отвечает бизнес-аналитик или аналитик данных, все остальные задачи, связанные с координацией работы команды разработчиков ложатся на плечи Архитектора программного обеспечения (Software Architect). Именно об этой специализации мы и будем говорить в этой статье.

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

В предыдущей статье, посвященной WAF мы рассмотрели отличия межсетевого экрана уровня приложений от средств обнаружения вторжений. Однако, на этом список новомодных сетевых средств защиты не исчерпывается.  В этой статье мы поговорим о межсетевых экранах нового поколения Next Generation Firewall, NGFW. Обычно NGFW называют межсетевой экран для глубокой фильтрации трафика, интегрированный с IDS/IPS и обладающий возможностью контролировать и блокировать трафик на уровне приложений. Под такое, достаточно емкое определение подпадает целый ряд решений, обладающих различным функционалом.

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

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

В этой статье мы рассмотрим более свойственные именно для языка Python уязвимости. И начнем мы с такой интересной темы как десериализация.

Понятие межсетевого экрана Firewall, я думаю, известно всем. Межсетевой экран позволяет разграничить сети, разрешив доступ только по определенным адресам и портам. Однако, межсетевые экраны разбирают трафик только до транспортного уровня, то есть извлекая из пакетов информацию о портах. Выше обычный МЭ при разборе пакета не поднимается. Но для обеспечения безопасности на уровне приложений необходимо разбирать пакеты до верхнего уровня. Такая необходимость возникает при защите прежде всего веб ресурсов. В этой статье мы поговорим об использовании Web Application Firewall.

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

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

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

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

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

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

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

По сути, Docker Compose это тот же Docker, но позволяющий автоматизировать работу с более сложными приложениями. Кроме того, для сценариев с одним контейнером использование Docker Compose обеспечивает независимую от инструмента конфигурацию таким образом, чего не делает отдельный файл Dockerfile. Параметры конфигурации, такие как подключение тома для контейнера, сопоставления портов и переменные среды, могут быть объявлены в файлах docker-compose YML.

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

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

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

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

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

В предыдущей статье мы развернули связку Prometheus+Grafana и теперь самое время подключить источники и настроить визуализацию. Но прежде напомню, с каких элементов ИТ инфраструктуры мы собираемся собирать метрики. Прежде всего это оборудование, операционные системы и дополнительное ПО, то есть все то, без чего нормальное функционирование нашего приложения было бы невозможно. Затем мониторинг самого приложения, например, какие компоненты расходуют больше тех или иных ресурсов. И наконец, мониторинг бизнес-логики приложения. Это может быть например сбор информации об активностях пользователей, поступлениях денежных средств и т.д.

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

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

В статье мы будем говорить о встроенных в Kafka механизмах защиты и не будем касаться использования каких-либо наложенных средств.

В этой теме мы продолжим рассмотрение файловой системы BTRFS и рассмотрим такую сложную и неоднозначную тему как кэширование. Типичная проблема, которую пытаются решить с пользователи это использование большего дискового объема при сохранении скорости. То есть, мы можем купить SSD диск, но стоимость хранения 1 Гигабайта на таком диске существенно больше стоимости хранения гигабайта на обычном HDD. Но зато SSD быстрее и за это все так любят эти диски. Задача заключается в том, чтобы постараться совместить скорость HDD со стоимостью хранения в HDD. Посмотрим, как в этом может помочь BTRFS и какие есть подводные камни у таких решений.

В качестве примера мы будем разворачивать кэширование на SSD диске с помощью Bcache.

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

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