В современных IT-инфраструктурах TLS-сертификаты используются практически везде: от публичных веб-сайтов до внутренних микросервисов и IoT-устройств. При этом многие системы используют самоподписанные сертификаты (self-signed certificates), особенно во внутренних сетях и тестовых средах.

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

Всем привет! Сегодня хочу затронуть «стыдную» тему – то, о чем ни вендоры, ни интеграторы, ни даже сами заказчики на уровне менеджмента обычно не говорят.

Привилегированные пользователи ненавидят PAM.

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

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

● Отрицательное влияние PAM на UX;

● Восприятие PAM как инструмента слежки;

● Проблемы с надежностью.

Давайте разберем каждую из них подробнее.

Влияние на UX

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

● Необходимость для работы с защищаемыми ресурсами применять на АРМ какие-то агенты/клиенты от вендора PAM (либо вовсе – безальтернативное использование браузера в качестве административного клиента);

● Не поддерживаются, либо требуют от пользователя дополнительных телодвижений часть обычных для администратора операций, таких как передача файлов, работа с буфером обмена, sudo и т.п. (в наиболее одиозных ситуациях – буфер обмена работает только в одном направлении из-за того, что сессия транслируется как поток графики);

● «Лишние» и лишние шаги при доступе к ресурсу. Иногда пользователей может в принципе раздражать необходимость зайти в ЛК или предъявлять второй фактор – все-таки тут больше действий, чем при простом подключении, скажем, по SSH или RDP. Но бывает и так, что у вендора не пробрасываются «креды» и состояние аутентификации: зашел пользователь в личный кабинет, предъявил «креды», выбрал ресурс для доступа – и на каком-нибудь шлюзе/прокси/jump ему опять надо предъявлять те же «креды». В числе моих «любимых» – накладываемая на пользователя обязанность указать причину, по какой нужен доступ. Как правило, в реальной практике туда пишут нечто вроде: «Работа». Как эта информация используется потом – остается только гадать;

Идеальная система аутентификации создает максимум препятствий для злоумышленников и минимум — для легитимных пользователей. Но на практике приходится искать компромисс между надежностью и удобством, например, устанавливать требования к паролям по длине и сложности. Классические технологии единого входа (SSO), среди которых SAML, OIDC и Kerberos закрывают часть этих вопросов: упрощают доступ для сотрудников и централизуют аутентификацию в определенные системы, однако имеют собственные недостатки — в первую очередь, они связаны многообразием систем, используемых в реальных enterprise-инфраструктурах, длительностью сессии и других аспектах, о которых мы поговорим в статье. Меня зовут Дмитрий Грудинин, я владелец линейки продуктов Avanpost Access, и сегодня я на примере нашей технологии Avanpost Unified SSO расскажу, как решить эти проблемы.

Немного цифр

В этом году команда крупного американского телекома изучила более 22 тыс. утечек, произошедших в компаниях из 139 стран. Информацию о киберинцидентах собирали по внутренним и открытым источникам, а также от партнеров — например, судебных экспертов и брокеров, занимающихся киберстрахованием. Анализ показал, что при атаках на инфраструктуру злоумышленники чаще всего выбирали путь наименьшего сопротивления, и их главной целью становились учетные данные. Так, согласно отчету, 88% атак на веб-приложения осуществлялись с использованием украденных логинов и паролей. При этом значительная часть скомпрометированных комбинаций не отвечала даже минимальным требованиям к сложности [неудивительно, что количество успешных брутфорс-атак с перебором паролей выросло втрое по сравнению с прошлым годом].

Привет, Хабр! Меня зовут Сергей Померанцев, я работаю в компании Avanpost и являюсь владельцем продукта Avanpost SmartPAM.

Я заметил, что на Хабре не так много действительно интересной информации о системах класса PAM (Privileged Access Management). Попробую это исправить и постараюсь периодически, скажем, пару раз в квартал, публиковать что-нибудь любопытное.

Итак, о Privileged Access Management. В целом, этот класс ПО оформился как обособленный, самостоятельный, в начале 2010-х гг, то есть – давно. Как это ни странно для столь зрелого направления, разные продукты абсолютно по-разному реализуют ключевую функцию: встраивание в привилегированную сессию и контроль происходящего там. Как следствие, одна и та же строчка о поддерживаемом протоколе в спецификациях (скажем, что поддерживается HTTP или RDP) у разных производителей означает совершенно разный пользовательский опыт.

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

Очевидно, что для решения задач управления привилегированным доступом PAM должен как-то встроиться в «механику» происходящего в сессиях. При этом привилегированные сессии разных типов имеют колоссальные различия в технологиях, при помощи которых организуются подключения (например, сеанс в конфигураторе 1С с точки зрения технологий – совсем не то же самое, что подключение к веб-консоли администрирования Unisphere дисковых массивов Dell/EMC Unity).

Привет Хабр! Я Дмитрий Закорючкин, в компании Avanpost я занимаюсь развитием нашей службы каталогов, Avanpost  Directory Service.

Сегодня я хотел бы поговорить о групповых политиках и их применимости в Linux-мире. Тема для меня близкая не только в связи с моей текущей деятельностью: так сложилось, что практически всю свою карьеру я так или иначе имел дело с AD DS, так что, надеюсь, рассказ предстоит интересный.

В современных гибридных инфраструктурах Linux-системы всё чаще соседствуют с Windows-доменами. Но если в мире Windows управление PKI давно стандартизировано, то автоматизация работы с сертификатами в Linux остаётся задачей «со звёздочкой»

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

Это Павел Еременко, владелец продукта DAG в компании Avanpost.

Как часто я слышал в выступлениях и читал в блогах продуктовых менеджеров фразы о том, что «нужно делать персонажей» или «строить карты пути пользователей»? Наверное, столько же раз, сколько встречался со скепсисом со стороны других менеджеров, которые считают всё это лишь красивыми ритуалами, имеющими мало отношения к практике. С теми же сомнениями мы приступали к новому продукту, пока один такой «ритуал» не привёл нас к ключевой фиче в продукте, которая позволяет повысить эффективность пользователей в основном сценарии на 60%.

За последние годы ассортимент решений по аппаратной аутентификации существенно расширился. На сегодня подавляющее большинство устройств пользователей поддерживают FIDO Passkeys, FIDO WebAuthn и много чего еще интересного, что позволяет по-новому взглянуть на привычную аппаратку. Несмотря на это, в корпоративном сегменте наблюдается рост популярности идеи использования СКУД-карточек для аутентификации одношаговой, двухшаговой и даже многофакторной. О причинах роста популярности СКУД мы можем только догадываться, но эта тенденция вызывает у нас опасения. 

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

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

Привет, Хабр. Это снова Алексей Деев, backend программист в компании Avanpost. Сейчас я хочу предложить вам отойти немного от написания кода и погрузиться в теорию: рассмотрим архитектуру Akka.net и проблемы, которые акторы помогут нам решить. Перед прочтением советую хотя бы бегло прочитать статью Введение в Akka.NET], чтобы иметь базовое представление о модели акторов в целом. Эту статью я не позиционирую как часть цикла, скорее, это небольшой спин-офф к основному сюжету.

Привет, Хабр! На связи Дмитрий Грудинин. Современные корпоративные веб-приложения и облачные сервисы в обязательном порядке требуют безопасной аутентификации и авторизации пользователей.

Как правило, для этого используются протоколы: SAML 2.0 или OpenID Connect (OIDC) на базе OAuth. Оба решают схожие задачи, связанные с делегированием ответственности за верификацию  пользователя стороннему доверенному провайдеру. При этом оба протокола скрывают за собой обширный арсенал различных вариантов использования, к тому же OIDC постоянно расширяется. 

В данной статье мы рассмотрим сценарий использования протокола SAML так сказать «for dummies». Идея статьи – без излишеств рассказать о том, что на самом деле нужно знать в SAML. И не рассказывать о том, без чего можно прекрасно обойтись.

Привет, Хабр! Это Алексей Деев, backend-разработчик в компании Avanpost. В этой статье я коротко расскажу о мире параллельной обработки данных с помощью акторной модели, приведу примеры кода на разных реализациях акторов под .net.

Привет, Хабр!
В этой статье мы расскажем, как работают современные системы управления доступом, и какие преимущества получает организация при использовании системы IAM Avanpost FAM и MFA+ вместе с аутентификаторами Рутокен.

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

Компания «Актив» производит три устройства, использующие три основные технологии многофакторной аутентификации:

Рутокен ЭЦП 3.0 — универсальный аутентификатор на основе технологии инфраструктуры открытых ключей (PKI). Может работать как аутентификатор и одновременно являться средством электронной подписи.

Рутокен OTP — аппаратное средство для генерации криптографически вычисляемых одноразовых паролей (алгоритм TOTP).

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

(Cпойлер) Преимущества аутентификаторов Рутокен

Аутентификаторы Рутокен:

Привет, Хабр! Меня зовут Александр Щербаков. Расскажу, как системы Privileged Access Management помогают контролировать действия привилегированных пользователей (таких как системные администраторы, управленцы, девопсы и проч.) с помощью сигнатурного анализа. Привилегированные пользователи обладают расширенным доступом к инфраструктуре. Их ошибки, небрежность или недобросовестные действия могут нанести организации большой вред.

Привет, Хабр! На связи Дмитрий Грудинин, ваш гуру многофакторной аутентификации.  Почва для размышления на сегодня: легко ли уследить за правами доступа, когда в компании работают тысячи сотрудников, используется множество ролей, а количество систем насчитывает десятки, и даже сотни?.. 

Рынок решений по ИБ предлагает 100500 аббревиатур:  IDM, IAM, IAG, DAG, etc. Давайте вспомним (ну или запомним) самые распространенные из них:

PAM (Privileged Access Management):

Всем привет!

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

О мотивации поговорили, давайте переходить к заявленной теме – как устроена наша система.

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

Привет, Хабр. На связи снова Avanpost. В этой статье мы решили поговорить про управление рисками доступа в привязке к решениям класса Identity Management/Identity Governance. Сам класс решений на Хабре освещен достаточно хорошо, в том числе, стараниями уважаемых конкурентов, но данная тема затронута слабо. И, как нам кажется, зря. Развитие западных решений и повторный виток интереса на западном рынке к классу обеспечены, в том числе, выходом этого функционала из статуса экспериментального на продуктивное плато.

В компании Avanpost мы занимаемся разработкой собственной службы каталогов Avanpost DS. Она плотно интегрируется с Microsoft Active Directory для обеспечения долговременного сосуществования инфраструктур: поддерживает различные виды доверительных отношений, включая двусторонние, специфичные расширения Kerberos и еще много закрытых функций, имплементация которых требует глубокого понимания устройства доменных служб MS. Для их реализации нам пришлось изучить множество документации, а кое-где и прибегнуть к реверс-инжинирингу. Соответственно, сейчас мы следим за изменениями, которые вносит MS в свой продукт и, в особенности, за изменениями в области безопасности, ведь чаще всего именно они приводят к нарушению работоспособности интеграций. 

Наткнувшись на статью Giulio Pierantoni на Medium, мы не смогли пройти мимо и решили поделиться ей с русскоязычным сообществом.

В предыдущей статье мы рассмотрели взаимодействие с VMware с помощью Python. В этой же обсудим взаимодействие с VMware с помощью Ansible.

Ansible — система управления конфигурациями, написанная на языке программирования Python с использованием декларативного языка разметки для описания конфигураций. Про Ansible на Хабре уже есть множество статей, но стоит еще раз упомянуть, что одним из ключевых свойств playbook'a является идемпотентность. Это значит, что сколько бы раз подряд вы не запускали свой playbook, результат будет один и тот же.