В данной статье я хотел бы затронуть тему применения требований стандартов безопасности при разработке ПО.

Основной материал подготовлен и составлен на основе требований стандарта PCI DSS. Данные требования также могут быть применены к обработке и хранению персональных данных в части выполнения требований GDPR.

Мой 12 летний опыт подготовки и успешного прохождения аудитов в разных странах мира показывает, что многие компании, которые занимаются разработкой ПО имеют системы и решения собственной разработки, которые обрабатывают карточные (и персональные) данные. А со стороны PCI Council есть даже отдельный стандарт PA DSS, который регламентирует требования к тиражируемому программному обеспечению. Вот только, большинство компаний в моей практике, будь то США, Британия или Китай, которые проходили аудит PCI DSS, не имели планов по тиражированию и продаже ПО. Более того, компании специально вносят ряд изменений в ПО используемое в рамках определенного проекта, чтобы не проходить аудит PA DSS, если это ПО внедряется на заказ. Потому не всегда выполнение требований стандарта и прохождение сертификации желанно и оправдано, а в данной статье приведены именно упомянутые стандарты, а не требования PA DSS.

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

Итак, давайте перейдем к детализации и описанию требований.

Общие разделы стандарта PCI DSS.

Требования PCI DSS (на основе требований PCI DSS 3.2.1)

1. Минимизировать места и сроки хранения критичных данных. В контексте данной публикации критичные данные это данные, безопасность которых регламентируется требованиями PCI DSS + GDPR (карточные и персональные данные).

Нужныли таковые данные впринципе или ихможно анонимизировать? Действительноли необходимо хранить критичные данные втаком объеме? Можноли избежать дублирования данных икак обеспечить ихминимизацию?

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

2. Критичные данные в базах данных, рекомендовано хранить в зашифрованном виде.

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

3. Клиентские сетевые потоки данных должны передаваться в зашифрованном виде.

Критичные данные должны передаваться по шифрованному каналу. Сетевые критичные данные должны передаваться по шифрованному каналу. Формально достаточно использование протокола безопасности TLS, но лучше обеспечить шифрование передаваемой информации на уровне ПО.

Соединение приложения с базами данных рекомендовано сделать шифрованным.

4. Если собираются фото платежных карт, они должны соответствовать требованиям безопасности.

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

5. Базы данных должны размещаться в отдельной подсети от подсети приложений.

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

6. Все тестовые параметры при переводе в эксплуатацию должны быть удалены.

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

7. Требуется использовать защищенные технологии и стойкие алгоритмы шифрования.

Не все алгоритмы шифрования считаются стойкими.

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

8. Запрещено хранить пользовательские пароли, только хеш (результат выполнения однонаправленного преобразования над паролем).

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

9. Проверка на OWASP TOP 10.

Необходимо проверять решение на основные уязвимости безопасности перед передачей его в эксплуатацию. Сам данный пункт достоин не то что одной, а целой серии статей от процесса проверок внутри Компании до внедрения систем Bug Bounty. Для начала рекомендуется проверять хотя бы на OWASP TOP 10.

10. Использование персонифицированных учетных записей.

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

11. Логирование действий с возможностью перенаправления во внешние системы.

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

12. Система разграничения полномочий с минимально необходимыми правами.

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

13. Шифрование безопасными ключами.

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

14. Требования к стойкости пароля.

Должны выбираться пароли которые не поддаются атаке перебором. Хранение и передача паролей должна быть обеспечена таким образом, чтобы минимизировать вероятность его компрометации (парольные хранилища, раздельное хранение и пр).

15. Пункт, который вероятно вы захотите дополнить самостоятельно

Приветствуем! На протяжении всего времени нашей работы с решениями компании Fortinet, а в частности с межсетевым экраном нового поколения FortiGate, одним из самых интересующих вопросов является контроль и отслеживание трафика отдельных пользователей или групп пользователей. Сегодня мы хотим подробно рассказать о механизме прозрачной аутентификации пользователей на межсетевом экране FortiGate с помощью технологии Fortinet Single Sign-On. Данная статья будет посвящена именно теоретическому аспекту FSSO, поскольку в данном случае без теории тяжело разобраться, что происходит на практике.

Single Sign-On (SSO) - механизм, позволяющий идентифицированным пользователям получать доступ к различным ресурсам в сети без повторной аутентификации. При работе с межсетевым экраном FortiGate, SSO реализуется с помощью FSSO (Fortinet Single Sign On) - комплекса программных агентов, который позволяет устройству FortiGate идентифицировать пользователей сети и тем самым контролировать их доступ к ресурсам сети, а также отслеживать трафик различных пользователей. Когда пользователь аутентифицируется в домене, FSSO агент отправляет на FortiGate имя пользователя, его IP адрес, а также список групп, к которым данный пользователь принадлежит. FortiGate использует данную информацию для того, чтобы разрешить или запретить данному пользователю доступ к сетевым ресурсам. FSSO обычно используется со службами каталогов, такими как Windows Active Directory или Novell eDirectory. Работа FSSO зависит от используемой службы каталогов. В данной статье мы будем рассматривать FSSO для Windows Active Directory (AD).

FSSO для Windows AD использует коллектор агента. Агенты для контроллеров домена (DC агент) также могут использоваться, в зависимости от режима работы коллектор агента. Существует два основных режима работы: DC Agent Mode (режим, в котором используются DC агент) и Polling Mode (в этом режиме используются только коллектор агенты). Также на FortiGate может использоваться Polling режим, который не требует установки сторонних агентов на сервера. Однако, данный вариант подходит только для простых сетей с минимальным количеством пользователей.

Для начала рассмотрим режим DC Agent Mode. Данный режим является рекомендованным для FSSO. Для него требуется:

DC агент, установленный на каждый контроллер домена - если в сети имеется несколько контроллеров домена, агент должен быть установлен на каждый из них;

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

Схема работы FSSO в режиме DC Agent Mode представлена на рисунке ниже:

1. При аутентификации пользователя DC агент перехватывает запись о входе на контроллере домена.

2. Затем DC агент выполняет DNS запрос для определения IP адреса пользователя и передает полученную информацию на коллектор.. После того, как коллектор получает информацию, он снова выполняет DNS запрос для того, чтобы определить, был ли изменен IP адрес пользователя.

3. После этого, вся информация о пользователе передается на FortiGate.

4. После того, как коллектор передал всю информацию о пользователе, FortiGate знает этого пользователя, его IP адрес и группы, к которым он принадлежит. Когда пользователь пытается получить доступ к интересующим его сетевым ресурсам (в том числе и к Интернету), FortiGate сравнивает IP адрес источника с IP адресами, находящимися в списке активных FSSO пользователей. Поскольку пользователь уже авторизован в домене, и FortiGate содержит информацию о нем, пользователь не будет авторизовываться повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает трафик данного пользователя.

Перейдем ко второму режиму - Collector Agent-Based Polling Mode. Данный режим не требует установки DC агентов на контроллеры домена. Однако, требования к установке коллектор агентов на сервер или сервера, принадлежащие домену, остаются. В таком случае коллектор агент периодически опрашивает контроллеры домена на предмет наличия событий log-on пользователей. Для этого могут использоваться различные методы:

NetAPI: Агент обращается к временным сессиям, созданным на контроллере домена в момент входа пользователей в домен, и вызывает функцию NetSessionEnum. Данный метод работает быстрее остальных, однако он может пропустить некоторые события входа при высокой нагрузке контроллера домена. Это связано с тем, что при высокой нагрузке сессии могут удаляться из оперативной памяти до того, как агент успеет к ним обратиться и передать информацию на FortiGate.

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

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

Схема работы Collector Agent-Based Polling режима представлена на рисунке ниже:

1. Пользователь аутентифицируется в домене, предоставляя свои учетные данные на контроллер домена;

2. Коллектор агент периодически (раз в несколько секунд) опрашивает контроллер домена на предмет наличия событий входа пользователей в домен;

3. Коллектор агент посылает полученную информацию на FortiGate;

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

И третий режим, который мы сегодня рассмотрим - Agentless Polling Mode. Процесс его работы схож с предыдущим режимом, однако вместо использования коллектор агента, FortiGate опрашивает контроллер домена самостоятельно. Из-за этого присутствует ряд ограничений:

• Требуется больше системных ресурсов;

• Происходит опрос только двух событий - ID 4768 и ID 4769. Для этого используется протокол SMB;

• Отсутствуют дополнительные возможности, которые можно использовать при наличии коллектор агента, например - проверка конечных станций.

Схема работы данного режима представлена на рисунке ниже.

1. FortiGate опрашивает контроллер домена для получения событий входа пользователей в систему.

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

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

Подведем итоги, выделив основные отличия в режимах DC Agent Mode и Polling Mode:

FSSO в режиме DC Agent Mode сложнее в инсталяции. Он требует установки коллектор агента, а также DC агента на каждый контроллер домена, в котором мониторятся события входа в систему. Но в то же время этот режим является более масштабируемым, поскольку работа по захвату событий входа реализуется DC агентами, которые и передают данную информацию на коллектор агент.

В Polling Mode коллектору необходимо опрашивать каждый контроллер домена раз в несколько секунд. При увеличении числа контроллеров домена, число запросов также растет. Даже если использовать несколько коллектор агентов - каждый из них должен опрашивать все контроллеры домена самостоятельно.

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

Для удобства, основные отличия в режимах были сведены в таблицу:

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

Youtube канал

Группа Вконтакте

Яндекс Дзен

Наш сайт

Телеграм канал

Привет, меня зовут Вика Бегенчева, я QA-инженер в Redmadrobot. Я расскажу, как злоумышленники крадут наши данные, и что можно сделать, чтобы от этого защититься.

Термин тестирование безопасности звучит довольно серьёзно. Многие боятся погружаться в эту тему, думая, что их ждут непроходимые дебри из непонятных слов, сложной литературы и загадочных аббревиатур. Я разберу основы тестирования безопасности и вы убедитесь, что на самом деле это просто и интересно.

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

Что хранят cookie

Допустим, мы зашли на сайт интернет-магазина ошейников для собак и выбрали французский язык (почему бы и нет). Добавили в корзину пару шлеек и поводок. Что будет, если мы закроем вкладку и зайдём на сайт снова? Всё останется прежним: интерфейс на французском и три товара в корзине. Магия? Нет, cookie.

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

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

Открываем панель разработчика в Chrome и переходим на рандомную статью на Хабре. Во вкладке Network находим первый запрос, и в хедерах реквеста видим как проставляются cookie:

И в респонсе (запросе) видим cookie:

Set-Cookie: fl=ru; expires=Fri, 25-Feb-2022 08:33:31 GMT; Max-Age=31536000; path=/

Тут уже работает логика и Google (если очень нужно): cookie типа fl=ru (параметр, вероятно, отвечающий за язык) или те, которые хранят товары в корзине постоянные cookie. Они не меняются, если пользователь их не трогает. Нас же интересуют временные или сессионные cookie. Они хранят информацию, которая помогает сайту понять, что это всё тот же пользователь в текущей сессии.

Например, при авторизации на сайте, в файл cookie проставляется условный session_id уникальный идентификатор сессии на данный момент времени, к которому привязаны текущий браузер и пользователь.

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

Как понять, что ваши данные в опасности

Если хакеру удастся угнать cookie пользователя, то он сможет действовать от его лица или же просто получит конфиденциальную информацию юзера. Как узнать, всё ли впорядке?

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

Во-вторых, нужно проверить, чтобы все конфиденциальные cookie были с флагом httpOnly и secure.

Cookie с флагом secure передаются на сервер только по протоколу HTTPS. Как правило, в этом случае есть сертификат SSL или TLS. Cookie с флагом httpOnly защищены от манипуляция JavaScript через документ, где хранятся cookie.

Открываем в Chrome инструменты разработчика и переходим во вкладку Application.

Проверяем, не хранятся ли пароли в LocalStorage в этом же разделе инструментов разработчика.

Теперь рассмотрим сценарии кражи пользовательских данных и как от них защититься.

HTTP и HTTPS

Гуляя по сайтам мы до сих пор встречаем предупреждения браузеров о незащищённом соединении. Иногда строгий браузер вообще не пускает нас на сайт, потому что не хочет нести за него ответственность. А чего он боится?

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

Сайты, которые общаются с сервером по протоколу HTTPS, используют сертификат TLS (его предшественник SSL). Такой сертификат может защищать как один домен, так и группу поддоменов.

Вернёмся в магазин мы решили всё-таки купить ошейник своей собаке. Переходим в корзину, вводим данные банковской карты для оплаты, нажимаем на большую кнопку Оплатить и наши данные улетают на сервер для обработки запроса. Допустим, злоумышленники решили перехватить данные нашей банковской карты в момент отправки запроса.

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

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

Чтобы защититься от кражи данных, убедитесь:

1. Что сайт общается через HTTPS, а не через HTTP.

2. Есть редирект с http:// на https:// злоумышленник может разместить ссылку с http://, тогда данные можно будет угнать. Редирект насильно переводит пользователя на https:// ради его же блага. И все счастливы.

3. Включен HSTS.

Brute force атаки

Допустим, в нашем любимом магазине ошейников для питомцев есть админка. Владелец сайта решил оставить ссылку админки по адресу https:// [].com/admin. Злоумышленник переходит по этому адресу и его ждёт страница входа в панель администратора. Допустим, наш хакер вводит логин admin, а пароль подбирает с помощью скрипта, который сам будет перебирать пароли.

Если логин верный, то узнать пароль дело нескольких часов. Запустил скрипт на ночь, лёг спать, а утром уже есть доступ к панели администратора. Такой перебор и есть brute force атака.

Защититься от взлома можно несколькими способами (про авторизацию/аутентификацию и oauth2 мы поговорим ниже). Но, если речь идёт о brute force атаке, то простейшая защита тут установка лимита на попытки ввода пароля.

Лимиты устанавливают в зависимости от специфики продукта и решения проектной команды:

• ограниченное число попыток в единицу времени;

• ограниченное число попыток с последующей блокировкой функционала (например, с восстановлением доступа через почту когда попытки закончились);

• установление тайм-аута после n попыток ввода.

Естественно, это не избавит от всех проблем, но сильно усложнит жизнь злоумышленнику.

Токены и сессии

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

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

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

Access-token определяет права пользователя и доступность ресурсов для него. Выглядит он как длинный набор символов. Можно сказать, что токен тот самый пропуск, который нам выдали в нашем тайном клубе.

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

Хорошей и частой практикой является использование время жизни токена. После логина и формирования access-токена, фиксируется время жизни дата, до которой токен считается действительным. Это как абонемент на месяц в тайный клуб.

На разных ресурсах, требования ко времени жизни токена разные. На одном сайте токен живёт год, а на другом всего лишь час. После того как срок действия токена истечёт, система попросит пользователя снова авторизоваться. Чтобы не вводить всё время логин и пароль после истечения access-токена, придумали refresh-токен.

У refresh-токена только одна цель обновлять access-токен. Это работает так:

• отправляем запрос на закрытый ресурс с истекшим аксесс-токеном;

• сервер возвращает ошибку о протухшем токене;

• клиент видит эту ошибку и сразу формирует запрос на обновление аксесс-токена;

• в хедеры этого запроса проставляется значение рефреш-токена;

• сервер сверяет рефреш-токен с базой данных, формирует новый аксесс-токен и отправляет его обратно на клиент;

• клиент автоматически повторяет запрос на закрытый ресурс уже с новым аксесс-токеном.

Готово! А пользователи сайта даже ничего не увидели и не поняли. Как этим пользуются хакеры?

Access- и refresh-токены это токены сессии. Если злоумышленнику удастся перехватить их, то он докажет, что он это мы, просто подставив в запрос. Он получит доступ к нашим ресурсам и сможет совершать действия от нашего имени.

Чтобы защититься, нужно:

• проверить, что токены сессии не храняться в файлах Cookie или LocalStorage;

• убедиться, что все запросы с токенами передаются по зашифрованному HTTPS;

• проверить, что нет доступа к ресурсу без предъявления токена отправить запрос без токена;

• проверить, что нет доступа с чужим токеном, а также проверить запросы с несуществующим токеном;

• проверить запросы с истекшим токеном;

• поменять в базе данных вручную время жизни токена (продлить/просрочить);

• удалить access-token токен из базы данных и отправить запрос.

Авторизация и аутентификация

Чтобы обеспечить безопасность системе и разрешить взаимодействовать с ней разным ролям пользователей (админы, модераторы и т.д.), важно понимать различия между авторизацией и аутентификацией.

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

Аутентификация это проверка на соответствие заявленного имени пользователя (паспорта) с идентификатором в системе (Лаврентий Куашников). Авторизация это предоставление нам прав в соответствии с нашей ролью в системе (отдельная комната для спикера).

Вернёмся к примеру с админкой нашего магазина ошейников. Снова переходим по адресу админки и нас ждёт страница с вводом логина и пароля. Логин это идентификатор пользователя в системе. Пароль это доказательство пользователя, что он это он (ведь только он может знать пароль).

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

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

А ещё наш сервер умный, и он знает, как реагировать на ошибки авторизации/аутентификации. У него есть два кода ошибок:

• 401 если логин/пароль не совпадают или если для доступа к ресурсу нужна аутентификация;

• 403 когда сервер понял, что за юзер к нему ломится, но отказывает ему в доступе.

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

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

Есть ряд проверок, которые снижают вероятность взлома:

• проверьте, что пароли авторизации не хранятся в cookie. Токены хранятся только в httpOnly куках;

• все запросы, где используется авторизация, передаются по зашифрованному соединению https.

Также проверьте пользовательский доступ к ресурсам с кэшем страницы:

1. Авторизуйтесь в системе.

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

3. Разлогиньтесь из второй вкладки.

4. Вернитесь на первую вкладку (кэш сайта покажет, что вы ещё в системе).

5. Попробуйте перейти на страницу с ограниченным доступом из первой вкладки, например, в личный кабинет.

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

Проверьте также время жизни токенов в системе. Можно попросить разработчика поменять время жизни на 3 минуты, вместо 7 дней. Также можно попросить поменять время сервера. Но время жизни токена в любом случае должно быть ограничено.

Проверьте API:

1. Отправьте запрос без хедеров авторизации.

2. Отправьте запрос с чужими значениями параметров авторизации.

3. Проверьте запрос с истекшим токеном или с тем же токеном после логаута (после логаута токен должен стать недействительным).

4. Проверьте, чтобы логин/пароль не передавались в параметрах запроса. Пример, как не нужно передавать логин/пароль в параметрах http запроса: http://site.ru/page.php?login=testqa&password=12345678.

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

1. Авторизуйтесь в системе в одном браузере.

2. Авторизуйтесь в системе в другом браузере (или во вкладке инкогнито).

3. Смените пароль в системе через первый браузер.

4. Проверьте доступ к ресурсам на втором браузере.

Тут мы проверяем, достаточно ли системе только сохранённых данных в cookie. При смене пароля все токены должны быть недействительными.

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

Третье:проверьте наличие постоянного тайм-аута сессии(Session-Timeout), они бывают нескольких видов. Наличиепостоянного тайм-аута запрещает доступ к ресурсу через n минут после авторизации. Наличиединамическоготайм-аута запрещает доступ к ресурсу через n минут после последнего запроса. Другими словами, динамический тай-маут закрывает доступ из-за вашего бездействия в системе.

И напоследок, не забудьте проверить, доступна ли двухфакторная аутентификация на сайте.

Двухфакторная аутентификация

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

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

Ещё неплохой практикой является использование на сайте протокола oAuth2. Простыми словами, oAuth2 это когда мы авторизуемся в одном сервисе с помощью другого. Например, когда регистрируемся/логинимся на сайте с помощью Gmail.

SQL-инъекции кода

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

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

ДОБАВИТЬ перец И УБРАТЬ сахар.

Вот и всё. Пранк удался. Но мы на стороне добра, так что вместо того, чтобы заменять заказ, мы проверим, как на кухне умеют фильтровать изменения. Как этим пользуются хакеры? SQL injection это намеренное внесение в базу данных извне. В нашем примере, кухня это база данных. SQL-запросы заказы от официантов.

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

http://some.site.ru/test/index.php?name=1 UNION SELECT 1,2,3,4,5 + &password=1234

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

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

Во-вторых, проверяем, чтобы при намерено кривом запросе не выводились ошибки, через которые можно сделать выводы о составе базы данных. Например, ошибка Unknown column 4 in order clause говорит о том, что данные из таблицы выбираются по трём колонкам или меньше.

Сегодня существует множество фреймворков и библиотек, которые предоставляют защиту от SQL-инъекций. Например, библиотека node-mysql для node.js.

XSS

XSS расшифровывается как Cross-Site Scripting. Эта уязвимость входит в список OWASP TOP-10. Её смысл в том, что злоумышленник принудительно внедряет JavaScript-код через инпут на сайте: в поле ввода пушит код, который сохраняется на странице. Впредь он будет исполняться каждый раз при вызове страницы. Это происходит потому, что на сайте отсутствует экранирование спец символов.

У хакера много вариантов воспользоваться этой уязвимостью: от отображения алерта (всплывающего окна) с рекламой до кражи cookie и редиректа на сайт-зеркало.

Не забывайте, что проверять наличие уязвимостей на чужом сайте по законодательству РФ (и многих других стран) запрещено. Это воспринимается, как попытка намеренного причинение вреда сайту. И что тогда делать?

Первым деломвводим во инпуты на сайте скрипты например. Если уязвимость есть, то при перезагрузке страницы появится алерт со значением test.

После этоговводим во инпуты строку:

\\ test :grin: /?.&&*@#$%^*;~`  <iNpUt type=text />фыва.&%\ <b>t_e_st</b>:sunglasses:<img src=x onerror=alert(xss)/>

Это универсальная проверка сразу на несколько кейсов.Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля. Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля.

В конце вводим скрипт или спецсимволы в окно фронтенда вставляем прям в код сайта через dev tools в браузере.

Напутствие

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

Думай, как хакер! Пытайся получить выгоду или навредить. Но только на своём проекте. Следи за новостями безопасности. Смотри реестр уязвимостей, читай статьи, которые пишут фирмы по обеспечению безопасности и мониторь новости про утечки данных. Обязательно пытайся разобраться в сути. И будь на стороне добра! :)

Безопасность. Что для вас значит это слово? В наше время компании тратят много усилий для того, чтобы их продукт был защищён от взлома и разного рода утечек информации. PVS-Studio решил помогать своим пользователям в данном направлении и расширять функционал в этой области. Поэтому одним из главных новшеств предстоящего релиза станет появление в анализаторе новых возможностей обеспечения безопасности и защищённости кода. Об этом и будет рассказано в данной статье.

Пару слов о нас в плане безопасности и защищённости

На данный момент PVS-Studio развивается не только как статический анализатор для поиска дефектов качества кода (quality control решение), но и как решение для поиска дефектов защищённости (security) и безопасности (safety). В контексте защищённости мы являемся SAST-решением. SAST (Static Application Security Testing) это разновидность статического анализа кода, ориентированная на поиск потенциальных уязвимостей защищённости. Такой анализ может выявить большое количество дефектов, в том числе даже тех, которые не успели проявить себя. Что касается безопасности, то это уже другое направление, которое ориентировано на обеспечение надёжности и отказоустойчивости программ.

Как вы понимаете из названия данной статьи, мы расширяем свой функционал в данных областях. Ранее у нас уже были различные таблицы соответствия стандартам безопасности и защищённости на нашем сайте. Но пользоваться этим было не очень удобно, ведь в непосредственно результаты работы анализатора эта информация не попадала. Теперь же мы не только делаем использование данных возможностей анализатора более дружелюбным для пользователей (например, путём интеграции в интерфейсы наших IDE плагинов), но и расширяем уже имеющуюся базу, добавляя поддержку новых стандартов. Дополнительным толчком к этому для нас стало упоминание PVS-Studio в отчете Static Application Security Testing, Q3 2020 от компании Forrester Research одного из ведущих исследователей влияния новых и инновационных технологий на бизнес-процессы и рынок. Подробнее об этом и том, как мы развились в SAST и safety решение, вы можете почитать тут.

Новые возможности

Ну и чтобы не тянуть время, давайте сразу обозначим, что конкретно было добавлено. Итак, новое, безопасное и классное в PVS-Studio:

• В анализатор добавлены новые группы диагностик OWASP ASVS и The AUTOSAR C++14 Coding Guidelines. Раньше соответствие диагностических правил PVS-Studio данным стандартам было доступно только на нашем сайте. Новых диагностических правил получилось более 50 штук!

• В результатах работы анализатора теперь выдаётся информация о соответствии срабатываний стандарту безопасного написания кода SEI CERT. Раньше эта информация также была доступна только на сайте PVS-Studio.

• Доработан интерфейс наших плагинов для Visual Studio, JetBrains Rider, IntelliJ IDEA для удобной работы с сообщениями анализатора, имеющими идентификаторы стандартов безопасности и защищённости.

• Поддержаны новые группы диагностик (OWASP, AUTOSAR) в PlogConverter.

• Поддержаны новые диагностики (OWASP, AUTOSAR) в SonarQube на уровне тегов. Провели работу по классификации наших диагностических правил по OWASP Top 10.

Примечание. В предыдущих версиях уже были поддержаны такие стандарты безопасности, как MISRA C:2012 и MISRA C++:2008. Для них на момент написания статьи реализовано 74 диагностических правила.

Ещё у нас поддержано соответствие наших диагностик наиболее распространённой классификации потенциальных уязвимостей CWE (Common Weakness Enumeration). Количество диагностик, которые подходят под данную классификацию у нас уже 514.

Новые группы диагностик

Поговорим немного о новых группах диагностик (OWASP и AUTOSAR), которые ранее присутствовали только на нашем сайте в виде сопоставлений. В новом релизе PVS-Studio 7.12 мы добавляем диагностики из этих стандартов в виде отдельных групп правил со своими номерами, документацией и всеми остальными присущими нашим диагностическим правилам вещами. То есть, проверяя проект, анализатор вам будет выдавать предупреждения для новых групп, по аналогии с остальными предупреждениями. Раньше из всех security и safety правил отдельные группы были только у диагностик PVS-Studio, соответствующих стандартам MISRA C и C++.

А вообще, что это за слова такие странные: OWASP, AUTOSAR? Давайте немного разъясним ситуацию.

The AUTOSAR C++14 Coding Guidelines это набор руководств для написания кода на языке C++14, который предназначен для работы в системах, где важны безопасность и отказоустойчивость. Основной сферой применения данного документа является автомобильная промышленность. Но он также может быть использован и в других отраслях, занимающихся разработкой встраиваемых систем.

Для данного стандарта мы создали отдельную группу и выделили ей номера с 3500 по 3999. Сопоставление этих диагностик со стандартом AUTOSAR вы можете посмотреть здесь.

OWASP Application Security Verification Standard это список требований к безопасности приложений и тестов, которые могут использоваться архитекторами программного обеспечения (ПО), разработчиками, тестировщиками, специалистами по защищённости приложений, продавцами и пользователями инструментов для разработки, сборки, тестирования и верификации защищённых приложений.

Как вы поняли, в отличие от стандарта организации AUTOSAR, OWASP ASVS не привязан к какому-то конкретному языку. Поэтому у нас реализованы диагностики этого типа на всех анализируемых нами языках (C, C++, C#, Java). Данные диагностические правила получили свою группу и номера с 5000 по 5999.

Теперь перейдём к CERT. SEI CERT Coding Standard это набор стандартов написания ПО для повышения надёжности и безопасности ПО на языках C, C++, Java и Perl. Эти стандарты разрабатываются координационным центром CERT (CERT Coordination Center, CERT/CC). Их сопоставление с правилами PVS-Studio представлено здесь.

Однако, в случае с CERT, мы не стали создавать новую группу диагностик. Причиной этому послужило то, что под этот стандарт попадает значительная часть наших диагностик общего назначения (General Analysis). Но не переживайте, информацию о том, что диагностика это конкретное CERT правило, вы всё равно узнаете. Она точно так же добавляется в результат работы анализатора, как OWASP ASVS или AUTOSAR C++14 Coding Guidelines.

При этом у нас продолжается поддержка таких стандартов, как MISRA C:2012 и MISRA C++:2008. Это стандарты разработки программного обеспечения, основная цель которых улучшить безопасность, переносимость и надёжность программ для встраиваемых систем (сопоставление).

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

В плагинах

Ну вот мы и добавили новые диагностики. А где же посмотреть результат их работы? Ну конечно же, в наших плагинах! На сегодняшний день мы поддерживаем отображение информации о стандартах безопасности в плагинах для трех IDE. Это Visual Studio (для версий с 2010 по 2019), JetBrains Rider и IntelliJ IDEA. Чтобы плагины могли отображать эти новые срабатывания, были сделаны следующие доработки:

• Добавлен новый столбец SAST, в который выводится вся информация о MISRA C:2012, MISRA C++:2008, The AUTOSAR C++14 Coding Guidelines, OWASP ASVS, SEI CERT Coding Standard из предупреждений.

• Убран столбец MISRA. Теперь вся информация заносится в столбец SAST. Этот же столбец будет использоваться в будущем и при поддержке нами новых стандартов.

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

Приведу пару картинок, чтобы вы имели представление, как это выглядит. В плагине для Visual Studio 2019 это выглядит вот так:

Точно такой же функционал мы добавили в Rider и в IntelliJ IDEA. Вот так это выглядит в Rider:

PlogConverter

Мы не могли забыть про нашу утилиту, которая позволяет конвертировать отчеты в различные форматы. Теперь все наши типы отчётов, в которые можно конвертировать результаты работы анализатора, поддерживают OWASP и AUTOSAR. Для примера посмотрим на, возможно, самый часто используемый тип для конвертации FullHtml. Этот тип позволяет вам изучать отчет в браузере: красиво и удобно, если нет возможности напрямую работать с плагином в вашей среде разработки. Плюс такой отчёт или ссылку на него удобно рассылать по почте.

Собственно, быстренько получили нужный файл и давайте теперь его посмотрим. Как вы видите, в заголовке можно увидеть новое поле Total Warnings (OWASP), которое говорит, сколько у вас потенциальных ошибок из этой категории:

Вот так отображается сам SAST столбец:

SonarQube

Хочется немного сказать и о нашей интеграции с SonarQube. Мы предоставляем плагин, который позволяет добавлять сообщения, найденные анализатором PVS-Studio, в базу сообщений сервера SonarQube. Далее вы можете фильтровать сообщения, осуществлять навигацию по коду для анализа ошибок, анализировать динамику количества ошибок, оценивать уровень качества кода проекта и так далее.

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

Также мы провели работу по классификации наших диагностических правил по OWASP Top 10. OWASP Top 10 это рейтинг самых опасных векторов атак на веб-приложения. Каждое место в этом рейтинге имеет описание и примеры сценариев атаки, а также ссылки на правила из стандарта OWASP ASVS и классификацию CWE, которые к нему относятся. Для примера вы можете посмотреть, как выглядит одно из мест рейтинга.

В OWASP Top 10 входят такие уязвимости, как:

1. инъекции;

2. сломанная аутентификация;

3. раскрытие конфиденциальных данных;

4. внешние объекты XML;

5. нарушенный контроль доступа;

6. неверная конфигурация безопасности;

7. межсайтовый скриптинг;

8. небезопасная десериализация;

9. использование компонентов с известными уязвимостями;

10. недостаточное ведение журнала и мониторинг.

В SonarQube же они отображаются вот здесь:

Сделано это по аналогии с тем, как у нас уже отображается CWE, который вы тоже можете видеть на скриншоте. Для этого мы используем специальную вкладку Security Category. Приведу пример, как выглядит заполненный CWE:

Заключение

Как вы видите, этот релиз у нас вышел достаточно насыщенным. Анализатор получил новые группы диагностик для стандартов OWASP ASVS и AUTOSAR C++14 Coding Guidelines. В результаты работы анализатора дополнительно стала выводиться информация о соответствии срабатываний стандарту SEI CERT. Интерфейс наших плагинов (Visual Studio, JetBrains Rider, IntelliJ IDEA) обновился для удобной работы с сообщениями анализатора, имеющими идентификаторы стандартов безопасности и защищённости. Ещё и PlogConverter с SonarQube научились работать с новыми группами диагностик (OWASP, AUTOSAR). И все это только то, что касается направления безопасности и защищённости!

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

Будьте счастливы и следите за состоянием своего кода. Спасибо за внимание!

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Nikolay Mironov, Paul Eremeev. PVS-Studio 7.12 New Features for Finding Safety and Security Threats.

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

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

Сценарий 1. Данные, которые лучше не хранить в облаке

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

В каждой сфере и в каждой компании есть данные, которые попадают в эту категорию. Например, в одной международной организации действуют очень строгие правила в отношении хранения ключей. Чтобы использовать для этого облачные платформы, ей необходимо получать специальное разрешение. Другая организация руководствуется собственным вариантом стандарта PCI DSS. Кроме того, у нее есть внутренние требования по управлению главными ключами с помощью аппаратного модуля безопасности в соответствии со стандартом FIPS 140-2 (уровень 3).

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

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

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

Сценарий 2. Требования местного законодательства и проблемы, связанные с ними

С развитием облачных технологий порядок их использования во многом зависит от требований законодательства в тех или иных странах. В этом сценарии организация хочет использовать облачную платформу из другой страны, но ее не устраивает, что у поставщика услуг будут ключи шифрования для всех данных. Если в том же облаке будут обрабатываться незашифрованные данные, поставщик услуг получит доступ и к ним. Некоторые организации также не хотят хранить ключи на криптографических устройствах (например, аппаратных модулях безопасности), управляемых поставщиком услуг (физически или с помощью ПО). Они справедливо полагают, что такой подход не соответствует принципу Hold Your Own Key (HYOK).

Проблемы могут быть связаны как с требованиями законодательства, так и с описанными выше причинами. Кроме того, регулирующие органы ЕС, России, Японии, Индии, Бразилии и других стран постоянно принимают новые акты, запрещающие хранить незашифрованные данные и/или ключи шифрования за рубежом. В качестве примеров можно привести отраслевые стандарты (например, TISAX в Европе), которые указывают или подразумевают, что у поставщика облачных услуг ни при каких обстоятельствах не может быть доступа к данным, а во многих случаях и к ключам шифрования. Однакопредварительные результаты опросауказывают на то, что возможны варианты, когда ключи шифрования находятся только у клиента (в то время как зашифрованные данные могут храниться за рубежом).

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

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

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

Сценарий 3. Централизованное управление ключами шифрования

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

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

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

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

Наконец, централизованное управление ключами позволяет пользователю облачного сервиса устанавливать правила доступа к ключам, а следовательно, и к неактивным данным.

Дальнейшие действия

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

• Прочитайтеэту статьюоб управлении ключами шифрования в облаке.

• Оцените риски для данных с учетом уязвимостей, нормативных требований, отношений между странами ит.д.

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

Ознакомьтесь ссервисамиотGoogle Cloud EKM (External Key Manager) и партнеров (Ionic, Fortanix, Thales ит.д.), которые позволяют перенести управление ключами из облака в локальную среду.

Напоминаем что при первой регистрации в Google Cloud: вам доступны бонусы на сумму 300 долларов США, а более 20 бесплатных продуктов доступны всегда. Подробнее поспециальной ссылке.

А так же выражаем благодарность за помощь в подготовке материала коллегам: Антон Чувакин, Иль Сон Ли,Звиад Кардава

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

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

SOAR это следующий шаг эволюции SIEM систем. Осуществляет оркестрацию и автоматизацию процессов управления разнородными ИБ- и ИТ- системами от разных производителей и обеспечивает реагирование на инциденты посредством заранее подготовленных планов реагирования (playbook) без необходимости переключения между различными консолями.

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

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

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

Согласно матрице приоритетов Security Operations от аналитического агенства Gartner за 2020 год, которую я привожу ниже, зрелость технологии XDR и SOAR находятся на одном уровне, в то время как выгода от этих технологий разная, высокая и средняя соответственно. Из матрицы недвусмысленно следует предположение о том, что XDR опережает по своим возможностям технологию SOAR.

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

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

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

В общем, лично я ставлю на XDR и его светлое будущее.

А у вас какие мысли?

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

1. runAsNonRoot

2. runAsUser / runAsGroup

3. seLinuxOptions

4. seccompProfile

5. privileged / allowPrivilegeEscalation

6. capabilities

7. readonlyRootFilesystem

8. procMount

9. fsGroup / fsGroupChangePolicy

10. sysctls

Подписывайтесь на телеграм-каналMops DevOps, чтобы не пропустить лучшие статьи, видео и митапы!

Pod vs Container settings

Параметры Kubernetes securityContext определены как в PodSpec, так и в ContainerSpec, а область действия указывается в этой статье с помощью аннотаций [P] и / или [C] рядом с каждым из них. Обратите внимание, что, если параметр доступен и настроен в обеих областях, параметр контейнера будет иметь приоритет.

Теперь, давайте рассмотрим на настройки securityContext:

1. runAsNonRoot[P/C]

Несмотря на то, что контейнер использует namespacesиcgroups для ограничения своих процессов, всего один неверный параметр развертывания, предоставит этим процессам доступ к ресурсам на хосте. Если этот процесс выполняется от имени пользователя root, он имеет тот же доступ, что и учетная запись root хоста, к этим ресурсам. Кроме того, если для уменьшения ограничений (например, procMountилиcapabilities) используются другие настройки модуля или контейнера, наличие корневого UID увеличивает риски их использования. Если у вас нет веской причины, вам никогда не следует запускать контейнер с правами root.

Итак, что делать, если у вас есть образ для развертывания, использующий root?

Часто базовые образы уже созданы и доступны для пользователей, но их использование остается на усмотрение групп разработки или развертывания. Например, официальный образ Node.js поставляется с пользователем node с UID 1000, от имени которого вы можете работать, но они явно не устанавливают его для текущего пользователя в своем Dockerfile. Нам нужно будет либо настроить его во время выполнения с помощью параметра runAsUser, либо изменить текущего пользователя в образе с помощью отдельного файла Dockerfile. Первый предполагает, что UID 1000 может читать файлы смонтированные в appvolume, также не очень распространенный вариант выполнение приложения в отдельном томе. Вместо этого давайте рассмотрим пример использования производного файла Dockerfile для создания собственного образа.

Не слишком углубляясь в создание образов, предположим, что у нас есть готовый пакет npm. Вот минимальный Dockerfile для создания образа на основе node: slim и запуска от имени заданного пользователя node.

FROM node:slimCOPY --chown=node . /home/node/app/   # <--- Copy app into the home directory with right ownershipUSER node                             # <--- Switch active user to nodeWORKDIR /home/node/app                # <--- Switch current directory to appENTRYPOINT ["npm", "start"]           # <--- This will now exec as the node user instead of root

Команда USER, делает node пользователем по умолчанию внутри любого контейнера, запущенного с этого образа.

Вариант 2: Пользователь не определен в базовом образе

Итак, чтобы мы сделали, если бы в базовом образе node пользователь не был бы определен? В большинстве случаем мы просто создаем его в новом Dockerfile и используем. Давайте расширим предыдущий пример, чтобы сделать это:

FROM node:slimRUN useradd somebody -u 10001 --create-home --user-group  # <--- Create a userCOPY --chown=somebody . /home/somebody/app/USER somebodyWORKDIR /home/somebody/appENTRYPOINT ["npm", "start"]

Как видите, единственное изменение - это команада RUN, которая создает нового пользователя - синтаксис может варьироваться в зависимости от дистрибутива базового образа.

ПРИМЕЧАНИЕ: это отлично работает для node.js и npm, но для других инструментов может потребоваться изменить владельца других объектов файловой системы. Если у вас возникнут какие-либо проблемы, обратитесь к документации по вашему инструменту.

2. runAsUser / runAsGroup[P/C]

Образы контейнеров могут иметь определенного пользователя и/или группу, настроенную для запуска процесса. Это можно изменить с помощью параметров runAsUser и runAsGroup. Часто они устанавливаются вместе с монтированием тома, содержащим файлы с одинаковыми идентификаторами владения.

...spec:  containers:  - name: web    image: mycorp/webapp:1.2.3  securityContext:    runAsNonRoot: true    runAsUser: 10001...

Использование этих настроек представляет опасность, поскольку вы изменяете параметры во время запуска контейнера, эти параметры могут быть несовместимы с исходным образом. Например, официальный образ сервера jenkins/jenkins CI работает как группа: пользователь с именем jenkins: jenkins и все его файлы приложений принадлежат этому пользователю. Если мы настроим другого пользователя, он не запустится, потому что этого образ не содержит этого пользователя в файле /etc/passwd. Даже если бы это было так, скорее всего, возникнут проблемы с чтением и записью файлов, принадлежащих jenkins: jenkins. Вы можете в этом убедиться, выполнив простую команду Docker:

$ docker run --rm -it -u eric:eric jenkins/jenkinsdocker: Error response from daemon: unable to find user eric: no matching entries in passwd file.

Как мы упоминали выше, это очень хорошая идея, чтобы процессы контейнера не запускались от имени пользователя root, но не стоит полагаться для этого на параметр runAsUser или runAsGroup. Что если кто-то удалить эти настройки? Не забудьте также установить для runAsNonRoot значение true.

3. seLinuxOptions[P/C]

SELinux - это система управления доступом к приложениям, процессам и файлам в системе Linux, настраиваемая через политики. Она реализует структуру модулей безопасности Linux в ядре Linux. SELinux основана на концепции меток и применяет эти метки ко всем элементам в системе, которые группируют элементы вместе. Эти метки известны как контекст безопасности - не путать с Kubernetes securityContext и состоят из пользователя, роли, типа и необязательного поля уровень - user: role: type: level.

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

Метки SELinux по умолчанию будут применяться средой выполнения контейнера при создании экземпляра контейнера. Параметр seLinuxOptions в securityContext позволяет применять пользовательские метки SELinux. Имейте в виду, что изменение маркировки SELinux для контейнера потенциально может позволить контейнерному процессу выйти из образа контейнера и получить доступ к файловой системе хоста.

По умолчанию метки SELinux будут применяться средой выполнения контейнера при создании экземпляра контейнера. Параметр seLinuxOptions в securityContext позволяет применять пользовательские метки SELinux. Имейте в виду, что изменение маркировки SELinux для контейнера потенциально может позволить контейнерному процессу выйти из образа контейнера и получить доступ к файловой системе хоста.

Обратите внимание, что эта функция будет применяться, только если операционная система хоста поддерживает SELinux.

4. seccompProfile[P/C]

Seccomp означает secure computing mode (безопасный режим вычислений) и является функцией ядра Linux, которая может ограничивать вызовы, которые конкретный процесс может делать из пользовательского пространства в ядро. Профиль seccomp - это определение JSON, обычно состоящее из набора системных вызовов и действия по умолчанию, предпринимаемого при возникновении одного из этих системных вызовов.

{    "defaultAction": "SCMP_ACT_ERRNO",    "architectures": [        "SCMP_ARCH_X86_64",        "SCMP_ARCH_X86",        "SCMP_ARCH_X32"    ],    "syscalls": [        {            "name": "accept",            "action": "SCMP_ACT_ALLOW",            "args": []        },        {            "name": "accept4",            "action": "SCMP_ACT_ALLOW",            "args": []        },        ...    ]}

Использован пример с сайтаhttps://training.play-with-docker.com/security-seccomp/

Kubernetes предоставляет механизм для использования настраиваемых профилей через параметр seccompProfile в securityContext.

seccompProfile:      type: Localhost      localhostProfile: profiles/myprofile.json

Доступно три значения для поля type:

• Localhost- в дополнительном параметре localhostProfile указан путь к профилю seccomp

• Unconfined- профиль не применяется

• RuntimeDefault- используется значение по умолчанию для среды выполнения контейнера (это значение по умолчанию, если тип не указан)

Вы можете применить эти настройки либо в PodSecurityContext, либо в securityContext. Если установлены оба контекста, то используются настройки на уровне контейнера в securityContext. Обратите внимание, что эти параметры актуальны для Kubernetes v1.19 - если вы развертываете более ранние версии, существует другой синтаксис; за подробностями и примерами обратитесь к документации на официальном сайте Kubernetes.

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

5. Избегайте Privileged Containers / Escalations[C]

Предоставление привилегированного статуса контейнеру опасно и обычно используется как более простой способ получения определенных разрешений. Среда выполнения контейнеров контролирует наличие флага privileged, предоставляет контейнеру все привилегии, но снимает ограничения, налагаемые cgroup. Она также может изменить Linux Security Module и позволить процессам внутри контейнера выйти из него.

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

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

Для более глубокого изучения Privileged Containers рекомендуем статьюPrivileged Docker containersdo you really need them?

6. Linux kernel capabilities[C]

Capabilities - это разрешения на уровне ядра, которые позволяют гранулярно управлять разрешениями на вызовы ядра, вместо того, чтобы запускать все от имени пользователя root. Capabilities позволяют изменять права доступа к файлам, управлять сетевой подсистемой и выполняет общесистемные функции администрирования. Вы можете управлять Capabilities через KubernetessecurityContext. Отдельные сapabilities или список, разделенный запятыми, могут быть представлены в виде массива строк. Кроме того, вы можете использовать сокращение -all для добавления или удаления всех capabilities. Эта конфигурация передается в среду выполнения контейнеров и настраивает capabilities при создании контейнера. Если в securityContext нет раздела capabilities, тогда контейнер создается с набором capabilities по умолчанию, который предоставляет среда выполнения контейнера.

securityContext:      capabilities:        drop:          - all        add: ["MKNOD"]

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

Обратите внимание, что при перечислении capabilities в securityContext вы удаляете префикс CAP_, который ядро использует в именах capabilities. Вы можете использовать утилиту capsh, она выводит информацию о включенных в контейнере capabilities в удобном формате о том, но оставляйте эту утилиту в итоговых контейнерах, так как это позволяет злоумышленнику легко определить, какие capabilities включены! Вы также можете проверить включенные capabilities в файле /proc/1/ status.

7. Запуск контейнеров с read-only filesystem[C]

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

8. procMount[C]

По умолчанию среда выполнения контейнеров маскирует определенные части файловой системы /proc изнутри контейнера, чтобы предотвратить возможные проблемы с безопасностью. Однако бывают случаи, когда к ним требуется доступ, особенно при использовании вложенных контейнеров, которые часто используются как часть процесса сборки в кластере. Есть только два допустимых параметра для этой записи: Default, который поддерживает стандартное поведение среды выполнения контейнера, или Unmasked, который удаляет все маскировки для файловой системы /proc.

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

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

9. fsGroup / fsGroupChangePolicy[P]

Параметр fsGroup определяет группу, в которой Kubernetes будет изменять разрешения для всех файлов в томах, когда тома монтируются в Pod. Поведение также контролируется fsGroupChangePolicy, для которого может быть установлено значение onRootMismatch или Always. Если установлено значение onRootMismatch, разрешения будут изменены только в том случае, если они еще не соответствуют разрешениям корневого каталога контейнера.

Будьте осторожны при использовании fsGroup. Изменение группового владения всем томом может вызвать задержки запуска Pod для медленных и/или больших файловых систем. Это также может нанести ущерб другим процессам, которые совместно используют тот же том, если их процессы не имеют разрешений на доступ к новому GID. По этой причине некоторые поставщики общих файловых систем, таких как NFS, не реализуют эту функцию. Эти настройки не влияют на ephemeral volume.

10. sysctls[P]

Sysctls - это функция ядра Linux, которая позволяет администраторам изменять конфигурацию ядра. В хостовой операционной системе Linux они определяются с помощью /etc/sysctl.conf, а также могут быть изменены с помощью утилиты sysctl.

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

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

Примечание о securityContext в процессе запуска

Во многих случаях описанные здесь параметры безопасности сочетаются с контролем доступа на основе политик (policy-based admission control), чтобы гарантировать, что необходимые параметры действительно настроены перед запуском контейнеров в кластер. Комбинируя параметры securityContext с PodSecurityPolicy, вы можете гарантировать, что запускаются только контейнеры, которые соответсвуют политике, принудительно применения определенных параметров securityContext. Параметры securityContext также могут быть добавлены к конфигурации контейнера во время запуска с помощью динамического контроля допуска (Dynamic Admission Control) и использования mutating webhooks.

Заключение

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

Телеграм-каналMops DevOps- анонсы вебинаров и конференций, полезные статьи и видео, а также регулярные скидки на обучение!

Введение

Базы данных это Святой Грааль для хакеров, поэтому их необходимо защищать с особой тщательностью. Это первая из серии статей, в которых мы дадим обзор best practice в обеспечении безопасности баз данных. Мы начнем с одной из самых популярных СУБД с открытым исходным кодом, PostgreSQL, и рассмотрим несколько уровней безопасности, о которых стоит задуматься:

• Безопасность на сетевом уровне

• Безопасность на транспортном уровне

• Безопасность на уровне базы данных

Безопасность на сетевом уровне

Файрволы

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

Следующий способ, который можно предпринять для повышения безопасности сервера базы данных, это заблокировать доступ к узлу, на котором работает база данных, на уровне порта, с помощью брандмауэра. По умолчанию, PostgreSQL прослушивает TCP-порт 5432. В зависимости от операционной системы существуют разные способы блокировки других портов. В Linux можно использовать iptables - наиболее доступную утилиту для управления файрволом:

# Make sure not to drop established connections.iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT# Allow SSH.iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT# Allow PostgreSQL.iptables -A INPUT -p tcp -m state --state NEW --dport 5432 -j ACCEPT# Allow all outbound, drop everything else inbound.iptables -A OUTPUT -j ACCEPTiptables -A INPUT -j DROPiptables -A FORWARD -j DROP

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

Приведенное выше правило PostgreSQL позволит любому подключаться к порту 5432. Его можно сделать более строгим, принимая подключения только с определенных IP-адресов или подсетей:

# Only allow access to PostgreSQL port from the local subnet.iptables -A INPUT -p tcp -m state --state NEW --dport 5432 -s 192.168.1.0/24 -j ACCEPT

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

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

ssh -f -N -T -R 5432:localhost:5432 user@<client-host>

Конечно, <client-host> должен быть доступным из узла PostgreSQL и иметь запущенного SSH-демона. Команда перенаправит порт 5432 на сервере базы данных на порт 5432 на клиентском компьютере, и вы сможете подключиться к базе данных через туннель:

psql "host=localhost port=5432 user=postgres dbname=postgres" 

Прослушивание адресов

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

listen_addresses = 'localhost, 192.168.0.1' 

Если клиенты, подключающиеся к базе данных, всегда находятся на одном и том же узле (или, скажем, совместно расположены в одном поде Kubernetes с PostgreSQL, работающим в качестве дополнительного контейнера), отключение прослушивания сокетов TCP может полностью исключить сеть из рассматриваемой картины. Запись пустой строки в параметр прослушиваемых адресов заставляет сервер принимать только соединения сокетов домена Unix:

listen_addresses = ''

Безопасность на транспортном уровне

Поскольку большая часть всемирной паутины переходит на HTTPS, найдется мало оправданий тому, чтобы не использовать надежное шифрование для соединений с базой данных. PostgreSQL поддерживает TLS (который по-прежнему называется SSL в документации, конфигурации и CLI по legacy-причинам) и позволяет использовать его для аутентификации как сервера, так и клиента.

Серверный TLS

Для аутентификации сервера сначала необходимо получить сертификат, который сервер будет предоставлять подключающимся клиентам. Let's Encrypt упрощает получение бесплатных сертификатов X.509, например, с помощью инструмента CLI certbot:

certbot certonly --standalone -d postgres.example.com

Учтите, что по умолчанию certbot использует вызов HTTP-01 ACME для проверки запроса сертификата, который требует действительного DNS для запрошенного домена, указывающего на узел, и порт 80, который должен быть открыт.

Если по какой-то причине вы не можете использовать Let's Encrypt и хотите сгенерировать все сертификаты локально, то можно использовать openssl CLI:

# Make a self-signed server CA.openssl req -sha256 -new -x509 -days 365 -nodes \    -out server-ca.crt \    -keyout server-ca.key# Generate server CSR. Put the hostname you will be using to connect to# the database in the CN field.openssl req -sha256 -new -nodes \    -subj "/CN=postgres.example.com" \    -out server.csr \    -keyout server.key# Sign a server certificate.openssl x509 -req -sha256 -days 365 \    -in server.csr \    -CA server-ca.crt \    -CAkey server-ca.key \    -CAcreateserial \    -out server.crt

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

Клиентский TLS

Аутентификация клиента по сертификату позволяет серверу проверить личность подключающегося, подтверждая, что сертификат X.509, представленный клиентом, подписан доверенным центром сертификации (CA).

Рекомендуется использовать разные центры сертификации для выдачи сертификатов клиенту и серверу, поэтому давайте создадим клиентский CA и воспользуемся им для подписи сертификата клиента:

# Make a self-signed client CA.openssl req -sha256 -new -x509 -days 365 -nodes \    -out client-ca.crt \    -keyout client-ca.key# Generate client CSR. CN must contain the name of the database role you# will be using to connect to the database.openssl req -sha256 -new -nodes \    -subj "/CN=alice" \    -out client.csr \    -keyout server.key# Sign a client certificate.openssl x509 -req -sha256 -days 365 \    -in client.csr \    -CA client-ca.crt \    -CAkey client-ca.key \    -CAcreateserial \    -out client.crt

Обратите внимание, что поле CommonName (CN) сертификата клиента должно содержать имя учетной записи базы данных, к которой подключается клиент. Сервер PostgreSQL будет использовать его для идентификации клиента.

Конфигурация TLS

Собрав все части вместе, теперь вы можете настроить сервер PostgreSQL для приема соединений TLS:

ssl = onssl_cert_file = '/path/to/server.crt'ssl_key_file = '/path/to/server.key'ssl_ca_file = '/path/to/client-ca.crt'# This setting is on by default but its always a good idea to# be explicit when it comes to security.ssl_prefer_server_ciphers = on# TLS 1.3 will give the strongest security and is advised when# controlling both server and clients.ssl_min_protocol_version = 'TLSv1.3'

Последняя часть настройки обновить файл host-based аутентификации сервера PostgreSQL (pg_hba.conf), чтобы требовать TLS для всех подключений и аутентифицировать клиентов с помощью сертификатов X.509:

# TYPE  DATABASE        USER            ADDRESS                 METHODhostssl all             all             ::/0                    certhostssl all             all             0.0.0.0/0               cert

Теперь пользователи, подключающиеся к серверу, должны будут предоставить действительный сертификат, подписанный клиентским CA:

psql "host=postgres.example.com \      user=alice \      dbname=postgres \      sslmode=verify-full \      sslrootcert=/path/to/server-ca.crt \      sslcert=/path/to/client.crt \      sslkey=/path/to/client.key"

Стоит обратить внимание, что по умолчанию psql не будет выполнять проверку сертификата сервера, поэтому для параметра sslmode необходимо установить значение verify-full или verify-ca, в зависимости от того, подключаетесь ли вы к серверу PostgreSQL, используя то же имя хоста, которое закодировано в поле CN его сертификата X.509.

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

Создайте ~/.pg_service.confсо следующим содержанием:

[example]host=postgres.example.comuser=alicesslmode=verify-fullsslrootcert=/path/to/server-ca.crtsslcert=/path/to/client.crtsslkey=/path/to/client.key

Теперь при подключении к базе данных вам нужно будет только указать имя службы и имя базы данных, к которой вы хотите подключиться:

  psql "service=example dbname=postgres"  

Безопасность на уровне базы данных

Роли

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

PostgreSQL имеет комплексную систему прав пользователя, основанную на концепции ролей. В современных версиях PostgreSQL (8.1 и новее) роль является синонимом пользователя, поэтому любое имя учетной записи базы данных, которое вы используете, скажем, с psql (например, user = alice), на самом деле является ролью с LOGIN атрибутом, который позволяет ей подключаться к базе данных. Фактически, следующие команды SQL эквивалентны:

CREATE USER alice;CREATE ROLE alice LOGIN;

Помимо возможности входа в систему, роли могут иметь иные атрибуты, позволяющие им обходить все проверки прав доступа (SUPERUSER), создавать базы данных (CREATEDB), создавать другие роли (CREATEROLE) и другие.

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

Предоставление роли прав доступа

В нашем воображаемом примере мы будем отслеживать инвентаризацию серверов:

CREATE TABLE server_inventory (    id            int PRIMARY KEY,    description   text,    ip_address    text,    environment   text,    owner         text,);

По умолчанию, конфигурация PostgreSQL включает роль суперпользователя (обычно называемую postgres), используемую для начальной загрузки базы данных. Использование этой роли для всех операций с базой данных было бы эквивалентно постоянному использованию root в Linux, что никогда не являлось хорошей идеей. Вместо этого давайте создадим непривилегированную роль и при необходимости назначим ей права доступа, следуя принципу наименьших привилегий.

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

-- Create a group role that doesn't have ability to login by itself and-- grant it SELECT privileged on the server inventory table.CREATE ROLE developer;GRANT SELECT ON server_inventory TO developer;-- Create two user accounts which will inherit "developer" permissions upon-- logging into the database.CREATE ROLE alice LOGIN INHERIT;CREATE ROLE bob LOGIN INHERIT;-- Assign both user account to the "developer" group role.GRANT developer TO alice, bob;

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

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

CREATE ROLE intern;GRANT SELECT(id, description) ON server_inventory TO intern;CREATE ROLE charlie LOGIN INHERIT;GRANT intern TO charlie;

Другие наиболее часто используемые привилегии объектов базы данных INSERT, UPDATE, DELETE и TRUNCATE аналогичны соответствующим SQL выражениями. Также вы можете назначить права для подключения к определенным базам данных, создания новых схем или объектов в схеме, выполнения функции и так далее. Взгляните на раздел Privileges документации PostgreSQL, чтобы увидеть весь список.

Безопасность на уровне строк

Одной из наиболее продвинутых функций системы привилегий PostgreSQL является безопасность на уровне строк, которая позволяет вам предоставлять привилегии подмножеству строк в таблице. Сюда входят как строки, которые могут быть запрошены с помощью оператора SELECT, так и строки, которые могут быть результатами операторов INSERT, UPDATE и DELETE.

Чтобы начать использовать безопасность на уровне строк, вам нужны две вещи: включить ее для таблицы и определить политику, которая будет контролировать доступ на уровне строк.

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

ALTER TABLE server_inventory ENABLE ROW LEVEL SECURITY;

Без какой-либо определенной политики PostgreSQL по умолчанию использует политику запретить, что означает, что никакая роль (кроме владельца таблицы, который обычно является ролью, создавшей таблицу) не имеет к ней доступа.

Политика безопасности строк это логическое выражение, которое PostgreSQL будет применять для каждой строки, которая должна быть возвращена или обновлена. Строки, возвращаемые оператором SELECT, проверяются на соответствие выражению, указанному в разделе USING, в то время как строки, обновленные операторами INSERT, UPDATE или DELETE , проверяются на соответствие с WITH CHECK выражением.

Давайте определим пару настроек, которые позволяют пользователям видеть все серверы, но обновлять только свои собственные, определенные полем владелец:

CREATE POLICY select_all_servers    ON server_inventory FOR SELECT    USING (true);CREATE POLICY update_own_servers    ON server_inventory FOR UPDATE    USING (current_user = owner)    WITH CHECK (current_user = owner);

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

Аудит

До сих пор мы в основном говорили о превентивных мерах безопасности. Следуя краеугольным принципам безопасности defence in depth, мы рассмотрели, как они накладываются друг на друга, чтобы замедлить продвижение гипотетического злоумышленника через систему.

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

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

; Log successful and unsuccessful connection attempts.log_connections = on; Log terminated sessions.log_disconnections = on; Log all executed SQL statements.log_statement = all

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

Для более продвинутого аудита PostgreSQL вы можете использовать сторонние решения, такие как pgAudit . Если вы используете self-hosted экземпляр PostgreSQL, вам придется установить расширение вручную. Некоторые размещенные версии, такие как AWS RDS, поддерживают его прямо из коробки, поэтому вам просто нужно включить его.

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

Заключение

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

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

Хабр, привет!

На днях мне посчастливилось поучаствовать тут (обойдемся ссылкой на запись, без прямой рекламы :-)), где обсуждалась такая новая тема на рынке ИБ, как XDR.

По горячим следам эфира зафиксирую основные тезисы: мои собственные мысли и факты относительно XDR и, в целом, отвечу на два важных вопроса: что такое XDR? зачем он стал нужен?

Что такое XDR?

XDR (Extended Detection and Response) это расширенное обнаружение и реагирование на сложные угрозы и целевые атаки. В основе решения данного класса лежат продукты от одного вендора, то есть, это, в большей степени, моновендорная история.

EDR (Endpoint Detection and Response) это ключевой элемент XDR. Без EDR не может быть XDR.

XDR должен строиться на сильном EDR, который сам по себе в рамках конечных точек должен охватывать большое количество источников данных: ПК, ноутбуки, виртуальные машины, мобильные устройства, плюс различные операционные системы (Windows, Linux, MacOS, Android, iOS, пр.).

XDR не равно EDR. XDR основан на расширении технологии EDR.

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

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

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

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

Защитные средства, такие, как EPP+EDR, шлюзы (почтовый и веб), NTA/NTDR, CASB, IDM и ряд других (зависит от конкретного вендора), а также решения по защите индустриально-специфичных систем (банкоматы, АСУ ТП, IoT, пр.) выступают сенсорами для XDR и, в том числе, элементами, через которые возможно проводить действия по реагированию.

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

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

XDR это, в первую очередь, облачная история, но XDR on-premise возможен как одна из опций. Это актуально для России, но не все вендоры на рынке это cмогут обеспечить. Если вендор исторически был и есть с on-premise решениями он поддержит историю с on-premise XDR, при этом, что логично, в том числе уйдет и в облако.

XDR концепция может лежать в основе предоставляемых сервисов со стороны MSSP провайдеров, оказываемого сервиса MDR, например.

XDR и MDR это про отличное дополнение друг друга, в первую очередь, для крупных организаций со своей выстроенной системой ИБ. Мы знаем, что для небольших организаций без ИБ-штата сервис MDR - это возможность быстро повысить свой уровень защиты за счет круглосуточного оказываемого сервиса. Для крупных это все же больше про высвобождение внутренних ресурсов под более важные задачи, про сложный качественный Threat Hunting (проактивный поиск угроз) и про рекомендации, в том числе, по реагированию. Крупные компании редко отдают на аутсорсинг вопрос, связанный с реагированием сторонними командами в их инфраструктуре. Вот как раз для таких организаций оказание MDR сервиса поверх выстроенного XDR будет идеальным и действительно мега эффективным.

Про основные отличия XDR и SOAR можно почитать в моей отдельной статье тут http://personeltest.ru/aways/habr.com/ru/post/547626/

Зачем стал нужен XDR?

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

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

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

На этом у меня всё! Дополняйте своими мыслями! До встречи!

Хотите изучить подсистему контроля доступа Windows за два час? Да ещё так знать эту тему, как ни один ваш преподаватель не знает? Хотите знать, как использовать функцию Windows API с самым длинным именем - AccessCheckByTypeResultListAndAuditAlarmByHandle? А увидеть код, создающий недокументированные структуры Windows? Тогда вам сюда!

В статье представлено описание библиотеки и набора тестов, которые позволят любому пользователю изучить в максимально полном объёме подсистему контроля доступа Windows при достаточно малых начальных знаниях. Рассматриваются вопросы работы с DACL, SACL, Conditional ACE, mandatory integrity checking и многие другие. Тесты позволяют пользователю самому произвольно менять входные данные и самостоятельно модифицировать их для более детального изучения нужных конкретному пользователю тем. Представленная библиотека позволят осуществлять разбор и создание всех внутренних структур подсистемы безопасности Windows, а также позволяет создавать access tokens с произвольными начальными данными.

Давным-давно я начал изучать подсистему безопасности Windows. Почитал отличные книги, однако каждая книга должна быть подкреплена прежде всего практикой. Так я начал свои практические эксперименты. Прежде всего, я начал со стандартной методики: создание некой файловой структуры с несколькими вложенными уровнями (директориями). На начальных этапах изучения такой экспериментальной площадки вполне хватало. Однако, когда я перешел к изучению DAC (Dynamic Access Control) тестовая площадка сильно усложнилась: мне уже пришлось разворачивать несколько виртуальных машин, на одной из которых был Windows Server, а на другой обычная клиентская ОС. Здесь уже потребовалось изучение процесса конфигурирования множества подсистем Windows Server, что несколько отвлекало от первоначальной задачи: изучение подсистемы безопасности. В конце концов у меня была написана достаточно развитая библиотека, которая позволяла мне получать в удобном для меня виде все значения различных структур, относящихся к подсистеме безопасности Windows, а также для большинства из них ещё и создавать их из ранее сохранённых значений. Но однажды мне пришла в голову идея, которая кардинально изменила (и сильно упростила) весь мой подход к изучению данной темы.

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

Я понял, что по сути вся подсистема безопасности Windows это только два понятия: токен (access token) и дескриптор безопасности (security descriptor a.k.a. SD). Если представить аналогию с обычной дверью, то токен это ключ, а дескриптор безопасности замок. Все остальные понятия/сущности, которые существуют в подсистеме безопасности Windows вторичны, и базируются только на использовании токенов и дескрипторов безопасности. И для изучения подсистемы безопасности надо только три этапа: 1) умение создавать свой токен из ранее сохранённых значений; 2) умение создавать дескриптор безопасности из ранее сохранённых значений; 3) вызвать корректную системную функцию для проверки доступа полученного токена к полученному дескриптору. Нет необходимости создавать сложную файловую структуру, нет необходимости в каком-либо сервере всё создаётся прямо на локальной машине с помощью только одной программы. Конечно, для корректного выполнения такой программы надо выполнить ряд условий, однако они крайне легко реализуются.

Программа должна быть запущена из-под административного пользователя. То есть достаточно выполнить вход обычным пользователем, но сам программный код должен быть запущен с помощью Run As Administrator. В моих тестах я использовал Visual Studio. Также должны быть сконфигурированы определённые привилегии для пользователя, из-под которого запускаются тесты: SeCreateTokenPrivilege (Create a token object), SeTcbPrivilege (Act as part of the operating system), SeImpersonatePrivilege (Impersonate a client after authentication).

Сам проект представляет из себя стандартный проект тестов для C++. То есть у него нет выходного файла и всё, что он производит это результаты тестирования. Описание всех тестов представлено в данном файле. А собственно сам проект находится вот здесь. Всё в исходных кодах, без внешних зависимостей, с лицензией типа делай всё, что хочешь, только оставь copyright. Кстати если у кого-то есть хорошие тесты, относящиеся к теме Windows Access Control, то предлагайте и я все их рассмотрю и, возможно, реализую в данном проекте.

В конце немного ответов на вопросы, поставленные мною же в начале статьи:

1.Как изучить подсистему контроля доступа Windows за два часа?

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

2.Как использовать функцию Windows API с самым длинным именем - AccessCheckByTypeResultListAndAuditAlarmByHandle?

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

3.Хотите увидеть код, создающий недокументированные структуры Windows?

Вот по этой ссылке вы можете найти функцию, создающую binary representation для типа данных CLAIM_SECURITY_ATTRIBUTE_V1. Сама по себе структура документирована в [MS-DTYP], однако описания, как именно она представляется в бинарных данных там нет. Эта структура нужна для задания resource attributes (понятие относится к DAC, Dynamic Access Control) для дескриптора безопасности (например для задания ресурсов для файла).

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

Установка Dockle

Трудностей при установке утилиты возникнуть не должно:

• Установка в OSX

$ brew install goodwithtech/r/dockle

• Установка в Linux

# RHEL$ VERSION=$( curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | \ grep '"tag_name":' | \ sed -E 's/.*"v([^"]+)".*/\1/' \) && rpm -ivh https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.rpm#Ubuntu$ VERSION=$( curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | \ grep '"tag_name":' | \ sed -E 's/.*"v([^"]+)".*/\1/' \) && curl -L -o dockle.deb https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.deb$ sudo dpkg -i dockle.deb && rm dockle.deb

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

Пример использования Dockle

Запускаем утилиту, указав имя образа. Если проблем нет, в консоль будет выведено сообщение PASS, а при обнаружении проблем или уязвимостей подробная информация о них:

Попробуем запустить Dockle в Docker, на скриншоте видно, что утилита отлично работает:

Основные функции и преимущества Dockle

• поиск уязвимостей в образах,

• помощь в создании правильного Dockerfile,

• простота в использовании, нужно указать только имя изображения,

• поддержка CIS Benchmarks.

Сравнение с другими инструментами

Существует большое количество похожих инструментов для диагностики безопасности, например: Docker Bench или Hadolint. Но в сравнении с ними Dockle более функциональна:

Применение Dockle в DevSecOps

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

По ссылкам ниже вы можете найти примеры того, как настроить системы CI / CD для работы с Dockle:

• Travis CI

• Gitlab CI

• Circle CI

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

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

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

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

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

История разработки

Сначала мы дописывали StripLinks, который в качестве примера транспортного агента представлен Microsoft, а затем прикрутили к нему функциональность опенсорсного ExchangeAttachmentFilter для фильтрации по имени файлов. Этого нам показалось мало и мы добавили туда анализ контента файлов алгоритмом Ахо-Корасик и регулярками, анализ текста, заголовков и темы письма, а еще обезвреживание автозапуска в pdf.

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

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

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

Разработанное мы решили выложить обратно в опенсорс вдруг кому-то послужит с пользой, как нам. Вот ссылка на репозиторий с агентом.

Как это работает

Архитектура агента предполагает модульность: есть кучка небольших компонентов, каждый из которых умеет проверять что-то одно:

• Совпадение отправителя и получателя письма

• Опасные шаблоны в теме письма

• Ссылки в тексте письма

• Опасные шаблоны в тексте письма

• Подделку MessageID

• Потенциально опасные заголовки письма

• SMTP сессию

• Проверку вложения по имени

• Проверку вложения YARA на наличие вредоносных сигнатур

• Проверку содержимого архивов остальными файловыми модулями

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

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

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

• Пропустить

• Отклонить

• Добавить в тему письма надпись "опасно"

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

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

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

Что мы хотим от публикации в опенсурс?

• Идеи, как можно было бы улучшить/поправить инструмент

• Помощь энтузиастов в развитии агента

• Дать коллегам по цеху инструменты и идеи, как можно оградить своих пользователей от почтовых угроз

Постепенно эволюционируя, каждая организация переходит от ручного grep логов к более современным инструментам для сбора, анализа логов. Если вы работаете с kubernetes, где приложение может масштабироваться горизонтально и вертикально, вас просто вынуждают отказаться от старой парадигмы сбора логов. В текущее время существует большое количество вариантов систем централизованного логирования, причем каждый выбирает наиболее приемлемый вариант для себя. В данной статье пойдет речь о наиболее популярном и зарекомендовавшем себя стэке Elasticsearch + Kibana + Fluentd в связке с плагином OpenDistro Security. Данный стэк полностью open source, что придает ему особую популярность.

Проблематика

Нам необходимо было наладить сборку логов с кластера kubernetes. Из требований:

• Использовать только открытые решения.

• Сделать очистку логов.

• Необходимо прикрутить LDAP, для разграничения прав.

Пререквизиты

Данный материал предполагает:

• Имеется установленный kuberenetes 1.18 или выше (ниже версию не проверяли)

• Установленный пакетный менеджер helm 3

Немного о helm chart

Наиболее популярным способом установки приложения в kubernetes является helm. Helm это пакетный менеджер, с помощью которого можно подготовить набор компонентов для установки и связать их вместe, дополнив необходимыми метриками и конфигурацией.

В своей практике мы используем helm chart от компании bitnami(подразделение vmware)

• собраны open source продукты на все случаи жизни.

• корпоративные стандарты по разработке чатов и докер образов

• красивая документация

• проект живой и активно поддерживается сообществом

Выбор стека

Во многом выбор стека технологий определило время. С большой долей вероятностью два года назад мы бы деплоили ELK стек вместо EFK и не использовали helm chart.

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

Elasticsearch и kibana поставляются с открытой лицензией, однако плагины для security и других вкусностей идут под иной лицензией. Однако компания Amazon выпустила плагины Open Distro, которые покрывают оставшийся функционал под открытой лицензией.

Схема выглядит примерно так

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

Минимальный деплой EFK стека (без Security)

Сборка EFK стека была произведена по статье Collect and Analyze Log Data for a Kubernetes Cluster with Bitnami's Elasticsearch, Fluentd and Kibana Charts. Компоменты упакованы в отдельный чат. Исходники можно взять здесь и произвести командой

helm dependency updatehelm upgrade --install efk . -f values-minimal.yaml

Из исходников values-minimal.yaml

elasticsearch:  volumePermissions:    enabled: truekibana:  volumePermissions:    enabled: true  elasticsearch:    hosts:    - "efk-elasticsearch-coordinating-only"    port: 9200# Пропишите свой хост, если используете ингресс  ingress:    enabled: true    hostname: kibana.local# Либо   service:    type: NodePort    port: 30010fluentd:  aggregator:    enabled: true    configMap: elasticsearch-output    extraEnv:    - name: ELASTICSEARCH_HOST      value: "efk-elasticsearch-coordinating-only"    - name: ELASTICSEARCH_PORT      value: "9200"  forwarder:#    Чтение логов с диска /var/log/containers/* отключено    enabled: false    configMap: apache-log-parser    extraEnv:    - name: FLUENTD_DAEMON_USER      value: root    - name: FLUENTD_DAEMON_GROUP      value: root

Кибана будет доступна по адресу http://minikube_host:30010/, либо http://kibana.local.

Как видим компонент fluentd forwarder не включен. Перед включением парсинга, я рекомендовал бы настроить на определенные логи, иначе еластику может быть послано слишком большое количество логов. Правила для парсинга описаны в файле apache-log-parser.yaml.

Как отправить логи в EFK

Существует много способов, для начала предлагаем либо включить fluentd forwarder, либо воспользоваться простейшим приложением на python. Ниже пример для bare metal. Исправьте FLUENT_HOST FLUENT_PORT на ваши значения.

cat <<EOF | kubectl apply -f -apiVersion: apps/v1kind: Deploymentmetadata:  name: helloworld  labels:    app: helloworldspec:  replicas: 1  template:    metadata:      name: helloworld      labels:        app: helloworld    spec:      containers:        - name: helloworld          image: sergbs/django-hello-world:1          imagePullPolicy: Always          ports:            - containerPort: 8000          env:            - name: FLUENT_HOST              value: "efk-fluentd-headless"            - name: FLUENT_PORT              value: "24224"  selector:    matchLabels:      app: helloworld---apiVersion: v1kind: Servicemetadata:  name: helloworldspec:  selector:    app: helloworld  ports:    - port: 8000      nodePort: 30011  type: NodePortEOF

По ссылке http://minikube_host:30011/ Будет выведено "Hello, world!" И лог уйдет в elastic

Пример

Включить fluentd forwarder, он создаст daemon set, т.е. запустится на каждой ноде вашего кубернетеса и будет читать логи docker container-ов.

Добавить в ваш докер контейнер драйвер fluentd, тем более можно добавлять более одного драйвера

Добавить в ваше приложение библиотеку, которая будет напрямую логировать. Пример приложения на python. Используйте его, как отладочное средство при установке EFK.

И как показывает практика, логировать напрямую эффективный, но далеко не самый надежный способ. Даже если вы логируете сразу в fluentd и в консоль. В случае потери конекта, во fluentd часть логов просто не смогут попасть и будут потеряны для него навсегда. Поэтому наиболее надежный способ, это считывать логи с диска для отправки в EFK.

Очистка логов.

Для очистки логов используется curator. Его можно включить, добавив в yaml файл:

elasticsearch:  curator:    enabled: true

По умолчанию его конфигурация уже предусматривает удаление через индекса старше 90 дней это можно увидеть внутри подчата efk/charts/elasticsearch-12.6.1.tgz!/elasticsearch/values.yaml

configMaps:  # Delete indices older than 90 days  action_file_yml: |-      ... unit: daysunit_count: 90

Security

Как обычно security доставляет основную боль при настройке и использовании. Но если ваша организация чуть подросла, это необходимый шаг. Стандартом де факто при настройке безопасности является интеграция с LDAP. Официальные плагины от еластика выходят не под открытой лицензией, поэтому приходится использовать плагин Open Distro. Далее продемонстрируем, как его можно запустить.

Сборка elasticsearch c плагином opendistro

Вот проект в котором собирали docker images.

Для установки плагина, необходимо, чтобы версия elasticsearch соответствовала версии плагина.

В quickstart плагина рекомендуется установить install_demo_configuration.sh с демо сертификатами.

FROM bitnami/elasticsearch:7.10.0RUN elasticsearch-plugin install -b https://d3g5vo6xdbdb9a.cloudfront.net/downloads/elasticsearch-plugins/opendistro-security/opendistro_security-1.12.0.0.zipRUN touch /opt/bitnami/elasticsearch/config/elasticsearch.ymlUSER rootRUN /bin/bash /opt/bitnami/elasticsearch/plugins/opendistro_security/tools/install_demo_configuration.sh -y -iRUN mv /opt/bitnami/elasticsearch/config/elasticsearch.yml /opt/bitnami/elasticsearch/config/my_elasticsearch.ymlCOPY my_elasticsearch.yml /opt/bitnami/elasticsearch/config/my_elasticsearch.ymlUSER 1001

Есть небольшая магия, ввиду, того что плагин дополняет elasticsearch.yml, а контейнеры bitnami только при старте генерируют этот файл. Дополнительные же настройки они просят передавать через my_elasticsearch.yml

В my_elasticsearch.yml мы изменили настройку, это позволит нам обращаться к рестам elasticsearch по http.

# turn off REST layer tlsopendistro_security.ssl.http.enabled: false

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

Запуск docker-compose с LDAP интеграцией

Запустим проект с помощью docker-compose up , и залогинимся на http://0:5601 под admin/admin

Теперь у нас есть вкладка Security

Можно посмотреть настройку LDAP через интерфейс кибаны

Настройки должны совпадать с файлами конфигурации. Стоит обратить внимание, что плагин хранит свои данные в индексе еластика, и файлы конфигурации применяет при инициализации, т.е. если индекс не создан. Если вы измените файлы позже то вам придется воспользоваться утилитой securityadmin.sh

docker exec -it elasticsearch /bin/bashI have no name!@68ac2255bb85:/$ ./securityadmin_demo.shOpen Distro Security Admin v7Will connect to localhost:9300 ... doneConnected as CN=kirk,OU=client,O=client,L=test,C=deElasticsearch Version: 7.10.0Open Distro Security Version: 1.12.0.0Contacting elasticsearch cluster 'elasticsearch' and wait for YELLOW clusterstate ...Clustername: elasticsearchClusterstate: YELLOWNumber of nodes: 1Number of data nodes: 1.opendistro_security index already exists, so we do not need to create one.Populate config from /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/Will update '_doc/config' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/config.yml    SUCC: Configuration for 'config' created or updatedWill update '_doc/roles' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/roles.yml    SUCC: Configuration for 'roles' created or updatedWill update '_doc/rolesmapping' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/roles_mapping.yml    SUCC: Configuration for 'rolesmapping' created or updatedWill update '_doc/internalusers' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml    SUCC: Configuration for 'internalusers' created or updatedWill update '_doc/actiongroups' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/action_groups.yml    SUCC: Configuration for 'actiongroups' created or updatedWill update '_doc/tenants' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/tenants.yml    SUCC: Configuration for 'tenants' created or updatedWill update '_doc/nodesdn' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/nodes_dn.yml    SUCC: Configuration for 'nodesdn' created or updatedWill update '_doc/whitelist' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/whitelist.yml    SUCC: Configuration for 'whitelist' created or updatedWill update '_doc/audit' with /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/audit.yml    SUCC: Configuration for 'audit' created or updatedDone with successI have no name!@68ac2255bb85:/$ 

настройка Ldap

Для настройки интеграции с LDAP необходимо заполнить соответствующие секции в elastisearch-opendistro-sec/config.yml, ссылка на официальную документацию по authentication

config:  dynamic:    authc:      # тут можно настроить авторизацию          authz:      # а здесь аутентификацию

В случае с Active Directory, необходимо будет изменить конфигурационный файл примерно так:

      # тут можно настроить авторизацию          ldap:        ...            hosts:              - ldaphost:389            bind_dn: cn=LDAP,ou=Example,dc=example,dc=ru            password: CHANGEME            userbase: 'DC=example,DC=ru'            usersearch: '(sAMAccountName={0})'            username_attribute: sAMAccountName

Не забудьте воспользоваться securityadmin.sh после изменения конфигурации. Процедура была описана в предыдущем параграфе.

Установка EFK + Opendistro в kubernetes

Вернемся к проекту с kubernetes, установим проект командой

helm upgrade --install efk . -f values.yaml  

Нам необходимо будет

Для настройка OpenDistro Security plugin мы скопировали файл конфигурации, которые поместим в секреты kubernetes.

  extraVolumes:  - name: config    secret:      secretName: opendistro-config      items:        - key: config.yml          path: config.yml  - name: roles-mapping    secret:      secretName: opendistro-config      items:        - key: roles_mapping.yml          path: roles_mapping.yml  extraVolumeMounts:    - mountPath: /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/config.yml      subPath: config.yml      name: config    - mountPath: /opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig/roles_mapping.yml      subPath: roles_mapping.yml      name: roles-mapping

Чтобы настройки применялись при команде helm upgrade, мы сделали job, который будет запускаться при каждой команде helm upgrade

apiVersion: batch/v1kind: Jobmetadata:    name: opendistro-config-reload    labels:        app.kubernetes.io/managed-by: {{.Release.Service | quote }}        app.kubernetes.io/instance: {{.Release.Name | quote }}    annotations:        "helm.sh/hook": post-upgrade        "helm.sh/hook-delete-policy": hook-succeededspec:    template:        metadata:            name: config-reload            labels:                app.kubernetes.io/managed-by: {{.Release.Service | quote }}                app.kubernetes.io/instance: {{.Release.Name | quote }}        spec:            initContainers:                - name: "wait-for-db"                  image: "alpine:3.6"                  command:                      - 'sh'                      - '-c'                      - >                          until nc -z -w 2 efk-elasticsearch-coordinating-only 9300 && echo elastic is ok; do                            sleep 2;                          done;            containers:                - name: opendistro-config-reload                  image: "{{ .Values.elasticsearch.image.registry }}/{{ .Values.elasticsearch.image.repository}}:{{ .Values.elasticsearch.image.tag }}"                  imagePullPolicy: {{ .Values.elasticsearch.image.pullPolicy | quote }}                {{- if .Values.elasticsearch.master.securityContext.enabled }}                  securityContext:                    runAsUser: {{ .Values.elasticsearch.master.securityContext.runAsUser }}                 {{- end }}                  command:                    - 'bash'                    - '-c'                    - >                       "/opt/bitnami/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh" -h efk-elasticsearch-coordinating-only -cd "/opt/bitnami/elasticsearch/plugins/opendistro_security/securityconfig" -icl -key "/opt/bitnami/elasticsearch/config/kirk-key.pem" -cert "/opt/bitnami/elasticsearch/config/kirk.pem" -cacert "/opt/bitnami/elasticsearch/config/root-ca.pem" -nhnv            restartPolicy: Never    backoffLimit: 1

Итоги

Если вы собираетесь организовать централизованную сборку логов для приложений под управление kubernetes, данный вариант мог бы стать вполне обоснованным решением. Все продукты поставляются под открытыми лицензиями. В статье приведена заготовка из которой можно создать production ready решение. Спасибо за внимание!

Предисловие

История берет свое начало в мае, когда в один из непогожих питерских дней, местная котельная решила отключить отопление. За окном было +10, влажность зашкаливала, ветер дул, а тепленькое солнышко не светило в окна от слова совсем (чертова северная сторона). В квартире стало ощутимо холодно. Кот слезал с теплых колен только дляопустошения миски. Мы же кутались в флиски и пледы. Через два дня такой жизни стало понятно - к черту все, нужен обогреватель! Требования были довольно просты - цена, определенная мощность, возможность эту самую мощность регулировать и какой-либо интерфейс (wi-fi\BT\ZigBee\485). Последнее хотелось больше для баловства и неведомого "а вдруг потребуется!". Оставлю за рамками статьи муки выбора, количество обогревателей на полках магазинов в конце весны и прочие приколы наших доставщиков. В итоге, я стал обладателем конвектора под брендом впрочем, если не показывать шильдик, то можно найти картинки аж трех производителей "клепающих" одинаковые модели. А если погуглить чуть поглубже, то окажется что в РФ франшиза на выпуск конвекторов под этими брендам принадлежит одной единственной конторе. И все встает на свои места - конвектор один, а шильдик лишь влияет на цену. Впрочем, мне то какая разница - грело бы, да управлялось.

Что-то я отвлекся. Итак, конвектор модульный:

• нагревательный блок

• блок с инвертором для управления

• Wi-fi свисток

Cобрано, запущено, кот согрет, самое время посмотреть, что там с интерфейсом. Приложение для мобилки подключилось к конвектору, залило настройки wi-fi сети и радостно предложило управлять обогревателем через интернет. И в принципе на этом можно было бы закончить, но в процессе эксплуатации появилось желание - время от времени использовать конвектор для просушки одного из помещений. Датчик влажности есть, к Home Assistant подключен, дело за малым, завести туда же конвектор. Тут меня ждало полнейшее разочарование - никакого API, никаких интеграций, вообще ни_че_го. Лан, инженером же работаю, не в первой городить программно-аппаратные решения.

Часть 0. Исходные данные

Первое, что делает любой инженер - берет отвертку и смотрит внутрь. А внутри USB-модуля оказалась железка HF-LPT220. Заботливый гугл находит:

• Статью (часть 1 и часть 2) пользователя @avstepanov Краткое содержание: Кондиционер, модуль такой же, попробовали wi-fi, API нет, решили проблему через управление по IR.

• Сайт производителя

Закатываем рукава достаем чемоданчик с инструментарием:

Часть 1. Wi-Fi!

Раз мобильное приложение общается с железкой через wi-fi, логично запустить сниффер и посмотреть что там бегает. Хорошо что микротик умеет "зеркалить" траффик в Wireshark (wiki mikrotik, инструкция попроще). Запускаем wireshark, включаем обогреватель и наблюдаем.

После отрабатывания DHCP-клиента, железка запрашивает IP адрес dongle.***.ru, где *** представительство в РФ (не вендор). Просто примем эту информацию к сведенью и сделаем вывод - в других международных регионах скорее всего будут свои фирмы-представители и, соответственно, адреса.

Происходит установка TCP-соединения и начинается обмен AT-командами

< - запрос от сервера, конвектору > - ответ от конвектора, серверу< AT+NDBGL=0,0< AT+APPVER> +ok< AT+WSMAC> =<ver>-20170810 . +ok=<MAC>

Данные команды повторяются несколько раз, как и ответы на них, видимо, происходит не очень быстрая обработка со стороны сервера.

Идем в документацию с сайта hi-flying и действительно находим:
AT+NDBGL - Enable\Disable UART information
AT+WSMAC - Set\Query Module MAC address parameters. Setting is valid after reset.
AT+VER - Query module software version information. AT+APPVER в документе отсутствует, т.к. модуль и прошивка датированы 2017 г. а вот документация на сайте 2016.

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

А вот вторая, заставляет задуматься.

Честно говоря, в эпоху пристального внимания к безопасности IoT, не надеялся увидеть что-либо дельное, однако Серьезно? Как-то это не похоже на зашифрованный TLS\SSL\Ipsec - траффик.

Cходу можно сделать предположение - последний байт, это контрольная, однобайтовая сумма. Открываем калькулятор и складываем AA+C+A+1+1A+1+6+5+1 = E8. Ясно, понятно. Начинаем жать все кнопки в приложении и обнаруживаем некоторые закономерности, попутно пишем на LUA dissector для Wireshark. Не парсить, же байты каждый раз =)

Получаем занятную штуку, на примере: aa 0c 0a 01 1a 01 06 00 00 00 00 05 00 01 e8

Отдельно хочется выделить запрос текущей конфигурации от сервера:

* На этапе инициализации используются дополнительные пакеты и команды, но оставим это за рамками статьи.

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

Посмотрим, какие порты открыты на сервере конвекторе. Linux\WSL > Bash > Netcat
nc -vnz <IP конвектора> 1-65000 2>&1 | grep succeeded

Через довольно продолжительное время, обнаружится открытый, 8899 порт. ONVIF у конвектора? Whaaat?! Но нам то что? Попробуем отправить пакет на включение и выставление настроек:
echo -e "\xAA\x0C\x0A\x01\x17\x01\x01\x00\x00\x00\x00\x00\x00\x00\xDA" |
nc <IP конвектора> 8899

И, внезапно, оно работает!

Есть одно, НО. При отправке запроса о текущей конфигурации (AA 03 08 10 04 C9), ответ отправляется не тому кто запросил, а на сервер с которым установлено соединение. Как итог, управление возможно только в слепую, никаких данных о включении, отключении, режиме и температуре получить невозможно.

Есть два способа изменить это поведение (сборка своей прошивки не в счет).
Первый. Так как в прошивке зашито DNS-имя, можно изменить IP-адрес в ответе DNS-сервера, так чтобы dongle.*****.ru ссылался на 192.168.0.* - т.е. прописать статическую DNS запись.
Плюс данного способа - все настройки делаются на маршрутизаторе\DNS-сервере в пару кликов.
Минус - очевидно, способ нерабочий, если ваш DHCP-сервер выдает клиентам публичные DNS-сервера (8.8.8.8, 1.1.1.1 и прочие "семейные DNS")

Второй способ приведен ниже, в части посвященной UART и касается изменении адреса сервера в модуле wi-fi.
Плюсы - гарантированная работа в ЛВС.
Минусы - жесткая привязка к конкретной ЛВС - это надо помнить.

Итак, запускаем (или пишем на коленке) на локальной машине простенький tcp-сервер. Отправляем железке AA 03 08 10 04 C9 в ответ получаем aa 0c 88 01 15 01 01 00 00 00 18 00 70 00 00 00 6e Теперь, все работает как надо.

Промежуточные результаты: Можно начинать писать свой шлюз\OPC-сервер\плагин для системы управления умным домом.

Часть 2. Android

А что если есть более простой способ рулить конвектором? Например, подключить систему управления умным домом напрямую к серверу и перекидываться JSON'ами. Реализовать такое управление, безусловно, проще.
Чтож, стоит посмотреть, как мобильное приложение общается с сервером. Запускаем wireshark, настраиваем mikrotik и смотрим. А посмотреть есть на что.

Приложение обращается к тому же самому IP - 82.209.**.** (правда я не увидел запроса к DNS, но возможно ОС взяла значение из кэша). А так же сморим первый TCP Stream. Да у нас тут целый запрос-ответ.

Ответ (К сожалению в ответе пришлось бы блюрить огромное количество данных, по этому вставка текстом, некоторые заголовки вырезаны):

HTTP/1.1 200 OKServer: nginx/1.12.2Content-Type: application/json;X-Powered-By: PHP/7.0.27X-Powered-CMS: <название одной популярной CMS>{  "result": {    "token": "<токен>",    "user": {      "name": ""    },    "enc_key": "<ключ>",    "server": {      "host": "dongle.<вендор>.ru",      "port": "10001"    },}

Что имеем? В запросе используется голый http, передающий в открытом виде:
appcode - бренд. Напомню, производитель изготавливает оборудование под разными брендами.
login - номер мобильного телефона, который является логином в приложении
password - пароль. Не хэш. Именно пароль, указываемый при регистрации, и использующийся для входа в приложение.

Интересное в ответе:
-На той стороне используется би_cms_.
-Нам передают токен
-Забегая вперед скажу, что нам передают ключ шифрования - enc_key

*Б - безопасность. Но давайте посмотрим что происходит дальше, а потом проанализируем все вместе.

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

IoZAWjxg/vHjEBEZvX1zTkrmbT2k8tVG0T1NjHjw2Qx1fwChQsv7PkRKKQ=6829b7302ad50470a5ddb3cd41566dafIoZAWjxg/vHjEBEZvX1zTgwVJIsFn6VqMtnyYurmE3p9TjpjjgxfpJDlRMyTKNqmZto39j4X4Y8nKH/XPIdynRedAM/4gQ4s9fXbd402ed9aec13b9a3ab4521212294f7cIoZAWjxg/vHjEBEZvX1zTgwVJIsFn6VqMtnyYurmE3p9TjpjjgxfpJDlRMyTKNqmZto39j4X4Y8nKH/XPIdynRedAM/4gQ4s9fXbd402ed9aec13b9a3ab4521212294f7c

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

Конец сообщения очень сильно что-то напоминает. Да и по закону жанра в конце сообщения должен быть хэш\CRC. Проводим некоторое время в калькуляторах перебирая алгоритмы и действительно, конец сообщения содержит свой хэш в MD5 (дайджест?). Ок.

Осталось определить алгоритм шифрования. Developer android заботливо подсказывает, что алгоритмов поддерживается дофига, но рекомендуется использовать AES256. Запомним.
На вопрос "Как определить алгоритм шифрования зная шифротекст?", гугл лаконично отвечает "Никак, анализируй приложение (де)шифровщик".

Забрались далеко, отступать не наши методы. Качаем APK, при помощи dex2jar конвертируем в jdk и открываем в JD.

Можно заняться полным реверсом (не ассемблер же), но быстрее будет запустить поиск по ключевому слову. Вопрос, что искать? Что-то отвечающее за шифрование - "encrypt"

Внезапно.

• Библиотека от espressif

• Библиотека от hyflying, с их SmartLink'ом.

• Три класса с реализующих AES. Причем во всех трех классах используются разные режимы шифрования.

Библиотеки от espressiа и hyflying можно отложить на потом, WifiUtils, логично предположить, отвечает за шифрование Wi-Fi. Остаются TcpServices, EncryptUtils и AES256Chipher. Заглянем в EncryptUtils и увидим:

public class EncryptUtils {private static final String AES_MODE = "AES/CBC/PKCS7Padding";private static final String CHARSET = "UTF-8";private static final String ENC_PASSWORD;private static final String HASH_ALGORITHM = "SHA-256";private static final String TAG = EncryptUtils.class.getSimpleName();private static final byte[] ivBytes;static {ENC_PASSWORD = EncryptUtils.class.getSimpleName().concat(EncryptUtils.class.getSimpleName());ivBytes = new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };}public static String decrypt(String paramString) {try {return decrypt(ENC_PASSWORD, paramString);}private static String decrypt(String paramString1, String paramString2) throws GeneralSecurityException {try {SecretKeySpec secretKeySpec = generateKey(paramString1);byte[] arrayOfByte = Base64.decode(paramString2, 2);return new String(decrypt(secretKeySpec, ivBytes, arrayOfByte), "UTF-8");}private static SecretKeySpec generateKey(String paramString) throws NoSuchAlgorithmException, UnsupportedEncodingException {MessageDigest messageDigest = MessageDigest.getInstance("SHA-256");byte[] arrayOfByte = paramString.getBytes("UTF-8");messageDigest.update(arrayOfByte, 0, arrayOfByte.length);return new SecretKeySpec(messageDigest.digest(), "AES");}

Краткое содержание:
Переменной ENC_PASSWORD два раза присваиваем имя текущего класса ("EncryptUtilsEncryptUtils"). Получаем хэш и на его основе генерим ключ, которым и дешифруем данные.

Запускаем Android Studio и пишем простенький код (или пользуемся он-лайн дешифровщиками) и скармливаем наш шифротекст.

Fail. Пробуем по другому, снова фейл. И так и сяк - Fail.

Окей, посмотрим что лежит во втором классе - AES256Chipher

paramString1 - шифротекстparamString2 - ключpublic static String decrypt(String paramString1, String paramString2) {         <отрезание и проверка MD5, not null и все такое прочее>           MessageDigest messageDigest = MessageDigest.getInstance("SHA384");          try {            byte[] arrayOfByte2 = messageDigest.digest(paramString2.getBytes("UTF-8"));            byte[] arrayOfByte1 = Arrays.copyOfRange(arrayOfByte2, 32, 48);            arrayOfByte2 = Arrays.copyOfRange(arrayOfByte2, 0, 32);                    try {              Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");              IvParameterSpec ivParameterSpec = new IvParameterSpec(arrayOfByte1);              cipher.init(2, new SecretKeySpec(arrayOfByte2, "AES"), ivParameterSpec);              return new String(cipher.doFinal(Base64.decode(paramString1, 0)));  }

Краткое содержание: берем пароль, считаем от него SHA384 (почему 384?), разбиваем на два байтовых массива [32-48] и [0-32].
Первый - вектор инициализации (IV)
Второй -ключ, который и скармливаем SecretKeySpec

Вроде, ничего криминального, все так делают. Внимание вопрос - что же у нас может выступать в роли пароля? Может быть, тот самый enc_key из JSONa передающийся открытым http?
Пробуем, и вуаля, сообщения расшифровываются. Внутри нас ждет тот самый REST API с командами getDeviceParams, setDeviceParams, changedDeviceParams. Можно начинать писать плагин для системы управления.

Возникают смешанные чувства:- Передача номера телефона и пароля в открытом виде. Я даже не знаю, что тут написать. Хэш? SSL\TLS? Не, не слышали. Зато, на сайте разработчиков гордо красуется "Входим в ТОП-100 разработчиков мобильных приложений".- Ключ шифрования (по сути) передается в открытом виде при установлении каждой сессии. А сессия создается при каждом запуске приложения. Нет, он не сохраняется. Открыл приложение, выставил температуру, закрыл приложение - такой же жизненный цикл имеет ключ. Т.е. нам достаточно перехватить начало одной, любой сессии и все, можем рулить железкой.- Зачем в приложении аж 3 класса реализующих AES? Ладно, тут ответ очевиден - "я его слепила из того что было"

Однако!- Благодаря этому, можно легко написать сторонне приложение\плагин\расширение для системы управления умным домом.Утечки ПД, нет, т.к. нет ФИО (оно вообще нигде не указывается, даже при регистрации)

Часть 3. UART

Как выяснилось в первой части, наш wi-fi свисток, это всего лишь "UART to Wi-Fi" преобразователь. Это значит, что мы можем при помощи Esp32\Arduino\RPI создать свою железку для управления конвектором - с MTTQ, bluetooth и прочими соединениями. Надо лишь узнать протокол.

Итак, свисток имеет разъем USB-AM, и подписи на плате (см. фото выше) +5v, Tx, Rx, GND. Дело за малым, взять кабель AM - AF, разрезать, зачистить и в параллель подключить логический анализатор. +5v, можно оставить в покое. Таким образом, сразу будем видеть и Тx и Rx - главное, определиться с какой стороны смотреть.

Запуск, тыканье в кнопочки на мобильнике и

что-то это напоминает.

UART to Wi-Fi оказался тупым конвертером. Никакой внутренней обработки, никакой логики. Формат сообщения такой же как и в первой части.

В Wireshark мы видели AT-команды. Да и в документации про это что-то было. Берем UART-USB, выставляем +5В и подключаем. Главное Tx и Rx подключить перекрестно (очевидно, но можно забыть). Запускаем Putty или любой другой терминальный клиент. Выбираем com-порт в документации указана скорость 115200, но по факту 9600.

Окей, железка что-то шлет в терминал, но на ввод не реагирует. Курим ман и находим - для перехода в режим настройки необходимо отправить "+++" (без enter'а), на что HF-LPT220 ответит "a" и нам надо в ответ послать такую же "a". Сделать это все надо за 3 с.

После данной эквилибристики, железка становится отзывчивой. Введем AT+H и увидим список доступных команд:

Можно позапускать всякое, но интерес представляет AT+SOCKB, который возвращает "+ok=TCP,10001,dongle.******.ru". Как внезапно

Попробуем заменить на что-нибудь свое?

"AT+SOCKB=TCP,10001,192.168.0.2". Возвращаем модуль в конвектор и смотрим в wireshark. Теперь железка пытается установить соединение не с сервером в интернете, а с ПК из локальной сети.

Выводы и заключение.

Буква S в аббревиатуре IoT обозначает Security

Существует три способа управления конвектором. Через сервер производителя (REST API), напрямую из ЛВС, через UART.

Остался открытый вопрос с модулем для HA - возможно никогда-нибудь, он будет написан=).

Translation of this article written by John Armstrong on Jan 20, 2021

Вступая в новый год, самое время поразмышлять о достижениях компании Tigera и о том, насколько Calico Enterprise изменилась за последний год и как она стала ведущим решением в сфере безопасности и мониторинга сетей и микросервисов Kubernetes. Опыт работы с пользователями корпоративного класса помог Tigera определить наиболее важные требования пользователей для успешного развертывания кластеров Kubernetes и успешного перехода от пилотных проектов к промышленным проектам. Эти знания помогли Tigera создать систему Calico Enterprise, архитектура которой и представлена ниже. Давайте рассмотрим этот многофункциональный слоёный пирог, снизу вверх.

Архитектура корпоративных решений Calico:

Calico Enterprise является родным для Kube

Cначала следует вспомнить несколько важных вещей. Calico Enterprise - это Kubernetes-native, Kube-native решение, в котором все, что делается, является расширением примитивов Kubernetes. Вся мощь Kubernetes используется путем интеграции с Kubernetes через API плюс путем создания собственного агрегированного API сервера. Операторная модель, взятая целиком из Kubernetes, используется для доступа и управления ресурсами, для выполнения таких функций, как, например, RBAC. Calico Enterprise, будучи родным для Kubernetes, по мере развития Kubernetes автоматически поддерживает взаимно совместимость.

Модель безопасности, работающая всюду

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

• Amazon Elastic Kubernetes Service (EKS) имеет встроенную поддержку Calico.

• Google Kubernetes Engine (GKE) имеет встроенную поддержку Calico.

• Microsoft Azure Kubernetes Service (AKS) имеет встроенную поддержку Calico.

• IBM Cloud Kubernetes Service (IKS) имеет встроенную поддержку Calico.

Почему это важно? Многие из клиентов Calico Enterprise используют стратегию нескольких облаков или гибридного облака (один из клиентов использует аж четыре облака) и в результате выбрали Kubernetes, потому что это абстракция, которая может работать в любой облачной инфраструктуре. А поскольку Calico Enterprise может работать в любом облаке и на любом дистрибутиве, это логичный выбор для облачных архитекторов и команд разработчиков, которым нужно решение, легко адаптирующееся при изменении требований. Многие компании сочетают Kubernetes и не Kubernetes среды и выбрали Calico Enterprise, потому что им требовалось единое решение, работающее в обеих этих средах.

Подключаемый, ориентированный на будущее Data Plane - Linux, Windows и eBPF

Calico Enterprise с самого начала разрабатывался с полностью подключаемым data planes, поэтому клиенты могут выбрать между разными data planes. Сетевой уровень Kubernetes выделяет три уровня data planes, и все они представлены в Calico Enterprise. Большинство пользователей используют стандартный data plane ядра Linux, потому что они еще не используют последние версии Linux, необходимые для поддержки eBPF. Некоторое количество рабочих приложений выполняется в Windows, и для этих клиентов предлагается то же единое решение, которое работает в Linux. Для пользователей, которые хотят расширить пределы производительности с использованием последних ядер Linux, Calico Enterprise предлагает eBPF data plane. В ближайшие несколько лет неизбежно появятся более быстрые data plane технологии, и Calico Enterprise планирует добавить их поддержку. Это еще один способ, которым Tigera защищает будущие инвестиции клиентов Calico Enterprise и демонстрирует приверженность предоставлять наиболее продвинутые, масштабируемые и надежные решения для пользователей Kubernetes.

Давайте посмотрим на четыре технологии в центре диаграммы, которые обеспечивают возможности безопасности и мониторинга.

Управление трафиком North-South

Calico Enterprise обеспечивает контроль безопасности как North-South, так и East-West трафика. В среде Kubernetes North-South принято обозначать трафик, который следует внутрь сети и из сети, а East-West - трафик, следующий внутри сети. Именно на стыке North-South между кластером Kubernetes и внешней средой мы сталкиваемся с наибольшими проблемами безопасности. Используя средства Calico Enterprise для управления политикой (policy) DNS и средства контроля входящего / исходящего доступа (ingress/egress access controls), пользователи контролируют North-South трафик. Корпоративный универсальный межсетевой экран Calico и интеграция с SIEM (Calico Enterprise universal firewall and SIEM integration) - это два метода, которые поддерживают интеграцию существующих средств управления безопасностью предприятия со средой Kubernetes.

Управление трафиком East-West

Контроль трафика East-West ограничивает область разрушения в случае нарушений безопасности, которые приводят к APT (advanced persistent threat). Есть несколько способов, с помощью которых Calico Enterprise помогает настроить эти средства контроля. Подход Calico Enterprise с глубокой защитой (defense-in-depth) обеспечивает защиту на трех уровнях: хост, контейнер / виртуальная машина и приложение. Используя единую структуру политики безопасности, вы настраиваете все эти уровни с помощью декларативной модели. Можно установить очень мелкие элементы управления доступом и фильтровать трафик на уровне протокола приложения, например, по протоколам http, https или MongoDB. Можно выполнять микросегментацию как для контейнерных рабочих нагрузок, так и для рабочих нагрузок виртуальных машин.

Безопасность и постоянное соответствие нормативам (Continuous Compliance)

По мере расширения зоны использования Kubernetes наблюдается потребность в еще более глубоком подходе к защите конфиденциальных данных, подпадающих под действие нормативных требований. Для обеспечения безопасности и постоянного соответствия нормативам (Continuous Compliance) Calico Enterprise обеспечивает шифрование данных в пути (data-in-transit encryption) с лучшей в отрасли производительностью, а также непрерывную отчетность о соответствии политик безопасности и средств управления. В Calico Enterprise есть богатый набор функций обнаружения вторжений (Intrusion Detection), который включает обнаружение различных угроз, настраиваемые оповещения об известных атаках, обнаружение аномалий поведения и приманки (honeypod). Calico Enterprise использует автоматизированный подход к обнаружению вредоносных программ и реагированию на них. Например, Tigera создала алгоритм машинного обучения в Calico Enterprise, который специально нацелен на обнаружение DGA (Domain Generation Algorithm), облегчая группам безопасности обнаружение DGA активности. Calico Enterprise может запускать автоматическое исправление, удаляя мошенническую микросервис из сети за миллисекунды, и генерируя затем рекомендации по политике предотвращения возможных атак.

Мониторинг и устранение неисправностей

Время простоя обходится дорого, а мониторинг распределенных приложений очень сложен. Calico Enterprise динамически генерирует диаграмму сервисов (Service Graph), которая позволяет легко понять, как микросервисы ведут себя и взаимодействуют друг с другом во время работы, упрощая тем самым процесс отладки и мониторинга. Динамическая диаграмма сервисов предоставляет очень богатый набор информации, включая информацию о том, в каких пространствах имен взаимодействуют рабочие нагрузки, подробную DNS информацию , подробные журналы событий (flow logs) для каждого отдельного потока в вашем кластере и то, как оцениваются сетевые политики. Горячие точки производительности автоматически идентифицируются и выделяются, а предупреждения (alerts) выдаются в контексте диаграммы сервисов. Пользуясь этой диаграммой, а также с помощью функции автоматического захвата пакетов, инженеры и программисты могут быстро находить источник проблемы на уровне приложения, процесса и сокета.

Единое управление и автоматизация

Унифицированные элементы управления обеспечивают безопасность и наблюдаемость в средах с несколькими кластерами, несколькими облаками и гибридными облачными средами, а также предоставляют единую панель для обеспечения согласованного применения элементов управления безопасностью. Они также поддерживают непрерывную интеграцию CI / CD для опытных пользователей. Calico Enterprise ввела в действие концепцию уровней политик, которые поддерживают делегирование полномочий по организационной структуре и областям ответственности для различных групп с разными потребностями (безопасность, сеть, платформа, DevOps, SRE, разработка). Уровни политик определяют порядок, в котором оцениваются политики сетевой безопасности, и используются для реализации средств управления безопасностью, которые не могут быть изменены или отменены неавторизованными пользователями. Например, средства контроля доступа в масштабе предприятия, созданные группой безопасности, имеют первостепенное значение и находятся на самом высоком уровне. Уровни политик могут объединяться в несколько кластеров с использованием возможностей централизованного управления Calico Enterprise, что позволяет использовать единое управление безопасностью, применяющиеся ко всем кластерам.

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

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

Что такое PendingIntent?

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

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

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

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

Распространенный случай

Самый распространенный и наиболее простой способ использования PendingIntent - это действие, связанное с уведомлением:

val intent = Intent(applicationContext, MainActivity::class.java).apply {    action = NOTIFICATION_ACTION    data = deepLink}val pendingIntent = PendingIntent.getActivity(    applicationContext,    NOTIFICATION_REQUEST_CODE,    intent,    PendingIntent.FLAG_IMMUTABLE)val notification = NotificationCompat.Builder(        applicationContext,        NOTIFICATION_CHANNEL    ).apply {        // ...        setContentIntent(pendingIntent)        // ...    }.build()notificationManager.notify(    NOTIFICATION_TAG,    NOTIFICATION_ID,    notification)

Мы видим, что создаем стандартный тип Intent, который будет открывать наше приложение, а затем просто оборачиваем его в PendingIntent, прежде чем добавить его в наше уведомление.

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

После вызова NotificationManagerCompat.notify() все готово. Система отобразит уведомление и, когда пользователь нажмет на него, вызовет PendingIntent.send() для нашего PendingIntent, запуская наше приложение.

Обновление неизменяемого PendingIntent

Вы можете подумать, что если приложению нужно обновить PendingIntent, то он должен быть изменяемым, но это не всегда так! Приложение, создающее PendingIntent, всегда может обновить его, передав флаг FLAG_UPDATE_CURRENT:

val updatedIntent = Intent(applicationContext, MainActivity::class.java).apply {   action = NOTIFICATION_ACTION   data = differentDeepLink}// Because we're passing `FLAG_UPDATE_CURRENT`, this updates// the existing PendingIntent with the changes we made above.val updatedPendingIntent = PendingIntent.getActivity(   applicationContext,   NOTIFICATION_REQUEST_CODE,   updatedIntent,   PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT)// The PendingIntent has been updated.

Чуть позже поговорим о том, почему может возникнуть желание сделать PendingIntent изменяемым.

Технология Inter-app APIs

Распространенный случай полезен не только для взаимодействия с системой. Хотя для получения обратного вызова после выполнения действия чаще всего используются startActivityForResult() и onActivityResult(), это не единственный способ.

Представьте себе приложение для онлайн-заказа, которое предоставляет API для интеграции с ним приложений. Оно может принять PendingIntent как extra к своему собственному Intent, которое используется для запуска процесса заказа еды. Приложение заказа запускает PendingIntent только после того, как заказ будет доставлен.

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

Мы создадим неизменяемый PendingIntent, потому что не хотим, чтобы приложение онлайн-заказа меняло что-либо в нашем Intent. Необходимо, чтобы его отправили в том виде, в каком он есть, когда заказ будет доставлен.

Изменяемые PendingIntents

Что если мы будем разработчиками приложения для заказа и захотим добавить функцию, позволяющую пользователю набрать сообщение, отправляемое обратно в вызывающее приложение? Возможно, чтобы вызывающее приложение могло показать что-то вроде: "Сейчас время PIZZA!".

Ответом на этот вопрос является использование изменяемого PendingIntent.

Поскольку PendingIntent это, по сути, обертка вокруг Intent, можно подумать, что существует метод PendingIntent.getIntent(), который можно вызвать для получения и обновления обернутого Intent, но это не так. Так как же это работает?

Помимо метода send() в PendingIntent, который не принимает никаких параметров, есть несколько других версий, включая эту, которая принимает Intent:

fun PendingIntent.send(    context: Context!,     code: Int,     intent: Intent?)

Этот параметр intent не заменяет Intent, содержащийся в PendingIntent, а скорее используется для заполнения параметров из обернутого Intent, которые не были предоставлены при создании PendingIntent.

Давайте рассмотрим пример.

val orderDeliveredIntent = Intent(applicationContext, OrderDeliveredActivity::class.java).apply {   action = ACTION_ORDER_DELIVERED}val mutablePendingIntent = PendingIntent.getActivity(   applicationContext,   NOTIFICATION_REQUEST_CODE,   orderDeliveredIntent,   PendingIntent.FLAG_MUTABLE)

Этот PendingIntent может быть передан нашему приложению онлайн-заказа. После завершения доставки приложение заказа может принять сообщение customerMessage и отправить его обратно в качестве дополнительного намерения, как это сделано ниже:

val intentWithExtrasToFill = Intent().apply {   putExtra(EXTRA_CUSTOMER_MESSAGE, customerMessage)}mutablePendingIntent.send(   applicationContext,   PENDING_INTENT_CODE,   intentWithExtrasToFill)

Тогда вызывающее приложение увидит дополнительное EXTRA_CUSTOMER_MESSAGE в своем Intent и сможет отобразить сообщение.

Важные соображения при объявлении изменяемости отложенного намерения (pending intent)

• При создании изменяемого PendingIntent ВСЕГДА явно задавайте компонент, который будет запущен в этом Intent. Это можно реализовать так, как мы сделали выше, явно задав точный класс, который будет его получать, либо с помощью вызова Intent.setComponent().

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

• Если вы попытаетесь переопределить значения в PendingIntent, который был создан с FLAG_IMMUTABLE, произойдет тихий сбой, и исходный обернутый Intent будет передан без изменений.

Помните, что приложение всегда может обновить свой собственный PendingIntent, даже если они неизменяемы. Единственная причина сделать PendingIntent изменяемым - если другое приложение будет иметь возможность каким-то образом обновить обернутый Intent.

Подробности о флагах

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

FLAG_IMMUTABLE: Указывает, что Intent внутри PendingIntent не может быть изменен другими приложениями, которые передают Intent в PendingIntent.send(). Приложение всегда может использовать FLAG_UPDATE_CURRENT для изменения своих собственных PendingIntent.

До Android 12 PendingIntent, созданный без этого флага, по умолчанию был изменяемым.

В версиях Android до Android 6 (API 23) PendingIntents всегда изменяемы.

FLAG_MUTABLE: Указывает, что Intent внутри PendingIntent должен позволять приложению обновлять его содержимое путем объединения значений из параметра намерения PendingIntent.send().

Всегда заполняйте ComponentName обернутого Intent любого изменяемого PendingIntent. Невыполнение этого требования может привести к уязвимостям в системе безопасности!

Этот флаг был добавлен в Android 12. До Android 12 любые PendingIntents, созданные без флага FLAG_IMMUTABLE, были неявно изменяемыми.

FLAG_UPDATE_CURRENT: Запрашивает, чтобы система обновила существующий PendingIntent новыми дополнительными данными, а не создавала новый PendingIntent. Если PendingIntent не был зарегистрирован, то регистрируется этот.

FLAG_ONE_SHOT: Позволяет отправить PendingIntent только один раз (через PendingIntent.send()). Это может быть важно при передаче PendingIntent другому приложению, если содержащийся в нем Intent может быть отправлен только один раз. Такое требование обусловлено удобством или необходимостью предотвратить многократное выполнение приложением какого-либо действия.

Использование FLAG_ONE_SHOT предотвращает такие проблемы, как "атаки повторного воспроизведения (replay attacks)".

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

Получение PendingIntents

Иногда система или другие фреймворки предоставляют PendingIntent как ответ на вызов API. Одним из примеров является метод MediaStore.createWriteRequest(), который был добавлен в Android 11.

static fun MediaStore.createWriteRequest(    resolver: ContentResolver,     uris: MutableCollection<Uri>): PendingIntent

Резюме

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

Мы также говорили о том, что PendingIntents обычно должен быть неизменяемым и что это не мешает приложению обновлять свои собственные объекты PendingIntent. Это можно сделать, используя флаг FLAG_UPDATE_CURRENT в дополнение к FLAG_IMMUTABLE.

Мы также говорили о мерах предосторожности, которые необходимо предпринять - заполнить ComponentName обернутого Intent - если PendingIntent должен быть изменяемым.

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

Обновления в PendingIntent были лишь одной из функций в Android 12, направленной на повышение безопасности приложений. Обо всех изменениях в предварительной версии читайте здесь.

Хотите еще больше? Мы призываем вас протестировать свои приложения на новой предварительной версии ОС для разработчиков и поделиться с нами своими впечатлениями!

Перевод материала подготовлен в рамках курса "Android Developer. Basic". Если вам интересно узнать о курсе подробнее, приходите на день открытых дверей онлайн, где преподаватель расскажет о формате и программе обучения.