Если ваш продукт хочет купить крупная компания — не спешите радоваться и открывать шампанское. Впереди ждет ад по приемке службы безопасности, который может растянуться на месяцы. Мы не знаем ни одной компании, которая учла все требования заранее и легко прошла приемку службой ИБ. Да и мы сами несколько раз переделывали продукт, чтобы соответствовать требованиям.
Чаще всего продуктовые команды фейлятся на одном и том же. В статье рассказали, как решить пять самых проблемных требований, чтобы продукт прошел приемку быстро и без критичных замечаний.
А в чем вообще проблема с приемкой по безопасности?
Функциональный заказчик оценивает ваш продукт с точки зрения удобства и решения его задач. Он может быть в восторге от функций и скорости работы, но как только дело дойдет до внедрения в инфраструктуру, вы неизбежно встретитесь со службой информационной безопасности.
Служба ИБ выставит список на 300 не очень понятных требований, и вашей команде придется учесть каждое из них. Иначе продукт не получится ввести в эксплуатацию, акты не будут подписаны, а команда не поедет на райские острова отдыхать.
Обычно эти требования взяты из разных законов, стандартов, распоряжений регуляторов и правил, исторически принятых в компании. Из них в вашем продукте чаще всего реализована только небольшая часть.
Например, большинство команд аутентифицируют пользователей по логину и паролю, разграничивают доступ на уровне ролей и в каком‑либо виде хранят журналы событий. Это — условная «гигиена» для любого приложения, к которой все давно привыкли.
Но для корпоративной инфраструктуры с чувствительными данными этого недостаточно. В требованиях ИБ могут быть те же аутентификация и журналирование, но уже с изменением парольной политики для разных групп пользователей.
Проблема в том, что после релиза любые изменения в продукте займут много времени и будут стоить дорого. Переделать формат журналов на этапе планирования займет один день, после релиза и перед приемкой у заказчика — до месяца.
Мы видели продукты, которые принимались с минимальными потерями за 3–4 недели, и те, которые переделывали полтора года — готовы ли вы к таким проектным рискам?
Если нет, то лучше заранее подготовиться к приемке — проверить свой продукт самостоятельно и выполнить самые проблемные требования.
Требование 1. Аутентификация по логину и паролю
Аутентификацию пользователей по логину и паролю делают все разработчики. Но часто они не учитывают:
запрет на установку ранее используемого пользователем пароля;
хеширование пароля с солью, уникальной для каждого пользователя, перед сохранением в базу;
настройку парольной политики в зависимости от потребностей заказчика;
проверку пароля на совпадение с одним из наиболее часто используемых пользователями.
Что сделать? Реализуйте аутентификацию через Active Directory — как правило, это позволяет закрыть большинство требований к паролям и управлению идентификаторами пользователей. Например, она закрывает первые 3 пункта из списка выше.
Требование 2. Стандартные образы Docker
Docker — часть современной культуры разработки: взял готовый образ, соединил со своим кодом и можно работать. Но де-факто в готовых образах могут присутствовать компоненты и настройки, которые запрещено использовать в корпоративных системах. Скорее всего, ваш продукт не пройдет проверку безопасности, если в нем:
не запрещено развертывание контейнеров на ОС без полного комплекта обновлений системы безопасности;
образы контейнеров содержат неиспользуемые библиотеки или пакеты;
в образах и контейнерах, конфигурационных файлах, параметрах запуска есть чувствительная информация, например пароли в файлах, hard-coded-пароли, ключи;
не реализовано взаимодействие с подсистемой управления секретами (Secret Management);
контейнеры запускаются с привилегированными или рутовыми правами;
разрешена запись данных в файловую систему контейнеров.
Что сделать? Проверьте свой продукт на предмет соответствия CIS Benchmarks. Для этого есть бесплатные утилиты, которые оценивают, какие параметры и настройки продукта могут вызвать проблемы с безопасностью. А конкретно для Docker рекомендуем воспользоваться CIS Docker Benchmarks.
Для наших собственных продуктов мы создаем контейнеры с нуля. Это занимает не так много времени, чтобы жертвовать безопасностью. Плюс правильно настроенный образ можно сразу использовать в следующих проектах.
Требование 3. Реализация криптографической защиты
Если для заказчика важна юридическая значимость и неотказуемость операций, вам придется озаботиться их подписанием. Например, если пользователь оплачивает услуги через мобильный банк.
Множество продуктовых команд в своих проектах реализуют криптографические функции, но делают это неправильно. Например, не учитывают детали процедур: забывают о проверке подлинности электронной подписи (ЭП) после того, как файл подписан. Или используют неподходящие алгоритмы. В итоге защита вроде бы есть, но ее стойкость вызовет вопросы со стороны экспертов в крупных заказчиках.
Если используете не встроенные криптографические функции, проверьте, что у вас:
есть лицензия на встраивание криптопровайдера или заключение аттестационной лаборатории о правильной реализации шифрования;
для криптографии не используются алгоритмы с коллизиями, такие как MD5;
подобрана корректная длина ключа. Например, при использовании CMAC/GMAC с AES, HMAC длина ключа должна быть ≥ 256 бит.
В российских компаниях чаще всего для шифрования и работы с ЭП применяют КриптоПро, сертифицированное ФСБ. Одно из условий его использования — не передавать СКЗИ за границу. Поэтому, если продукт должен работать за пределами РФ, то придется использовать дополнительный криптопровайдер.
Что сделать? Часть требований можно исключить, если для задач, решаемых приложением, достаточно реализовать простую электронную подпись. Например, отправлять пользователям пуш с одноразовым паролем для входа в приложение.
По закону ФЗ-63 «Об электронной подписи» к самому механизму пушей нужно определить в соглашении с пользователем:
когда документы с электронной подписью признаются равнозначными документам на бумаге;
порядок проверки электронной подписи;
правила определения лица, подписывающего электронный документ, по его простой электронной подписи;
обязанности лица, создающего и (или) использующего ключ простой электронной подписи, соблюдать его конфиденциальность.
Но для некоторых заказчиков этого будет недостаточно. Госорганы не могут использовать простую электронную подпись во внутреннем и межведомственном документообороте.
Требование 4. Журналирование
Журнал действий пользователя бывает полезен уже на этапе отладки продукта, поэтому обычно разработчики о нем не забывают и делают удобным — но для себя. Например, хранят короткие логи, в которых указано только время и описание события. Скорее всего, на приемке ИБ окажется, что такой журнал не соответствует требованиям безопасности.
Неподходящим может быть перечень событий, то есть список того, что именно должно быть записано в журнал. Но дополнить перечень несложно. Гораздо хуже, когда требованиям не соответствует формат журнала: способ записи ID, даты, описания события. И еще хуже, если содержимое журнала невозможно корректно выгрузить в систему для анализа и аудита.
Чтобы пройти приемку безопасности без вопросов, нужно журналировать:
факты выдачи, изменения и удаления прав для роли, а не только пользователя;
адреса рабочих станций, с которых выполняется действие;
полные описания всех событий, из которых должно быть понятно, кто, что и когда сделал.
Это только маленькая часть, которую обычно не включают разработчики в журналы.
Что сделать? Привести все журналы к единому стандарту, который подходит большинству корпораций. Для этого идеально подходит формат CEF (Common Event Format) — обычный формат событий, в котором предусмотрена вся важная информация. Почти у всех систем, которые собирают аналитику из журналов, есть стандартный адаптер для загрузки в CEF-формате.
Полное описание формата хорошо разобрал Hewlett Packard в методичке HPE Security ArcSight Common Event Format.
Требование 5. API для управления правами пользователей
Иногда внутренние требования компании, по сути, становятся стандартом, без которого ваш продукт не удастся внедрить. Например, во многих корпорациях нужен API для управления учетными записями. Официально это не зафиксировано, но на приемке безопасности наверняка всплывет и без корректной реализации ваш продукт не пропустят.
Для небольшой продуктовой команды это может показаться странным требованием. В небольших командах и компаниях редко используют IDM — системы для управления учетными записями пользователей. В них просто нет необходимости, потому что людей и ПО, которым нужны доступы, немного. Относительно просто вручную выдать доступ новому сотруднику на 5–6 систем и поддерживать учетки для нескольких десятков пользователей.
В энтерпрайзе всё иначе — в компании может быть сотня разных систем, с которыми работают тысячи сотрудников. Каждому новому сотруднику нужно выдать сто доступов, а если кто-то уволился, удалить. В этом случае IDM или аналогичный ему API необходим. Без него невозможно централизованно создавать, активировать и блокировать учетки, предоставлять и изменять права.
Что сделать? Быстрого решения у нас нет, продукт придется переписывать под ту IDM или шину данных, которую использует ваш заказчик. Можем дать несколько советов, какие методы API стоит реализовать как можно раньше:
методы создания учетной записи пользователя;
изменения полномочий пользователя;
блокировки/разблокировки;
изменения пароля;
изменения атрибутов учетной записи.
В качестве протокола для аутентификации, как и для реализации криптографических механизмов, рекомендуем не придумывать велосипед, а применять существующие протоколы и решения — для многих кейсов хорошо подойдет протокол OAuth 2.0.
Заключение. Как легко пройти приемку ИБ
Будет очень полезно узнать большинство требований на старте разработки продукта или проекта с крупным клиентом, и включить их в план разработки. Тогда команда не потратит лишние деньги, а главное, время на переделку после релиза.
Полный список будет зависеть от сферы заказчика, внутренних процессов, используемого ПО и сервисов, особенностей вашего продукта и т. д. Налаживайте контакт с заказчиком и его командой безопасности заранее. Как это сделать, мы рассказывали в одном из прошлых постов:
Безопасность + Разработка = ♡ Как выпускать релизы в срок и дружить с безопасностью
Многие требования будут одинаковы для любого энтерпрайза, их точно стоит учесть:
реализовывать аутентификацию через Active Directory;
образы Docker собирать самостоятельно и проверять их через CIS Benchmarks и CIS Docker Benchmarks;
в криптографии использовать простую электронную подпись, например через пуши с одноразовым паролем;
журналирование делать в CEF-формате;
API для управления правами пользователей включать в ТЗ на старте проекта.
Управление требованиями — это одна из базовых, но не единственная практика на пути к процессу создания приложений без дефектов. Про нее и связанные с ней подходы можно узнать из нашего руководства по безопасной разработке:
