Привет, Хабр! Меня зовут Андрей, в Selectel я руковожу отделом продуктов клиентской безопасности. Мы предоставляем и развиваем защищенную IT-инфраструктуру, помогаем клиентам хранить данные в соответствии с лучшими практиками и стандартами.
Мы видим, что число компаний, разрабатывающих SaaS-продукты, постоянно увеличивается. Растут и бизнесы, которые используют SaaS для обработки критически важных данных. Обе категории компаний встречаются среди наших клиентов. Таким образом, мы знаем потребности и разработчиков, и заказчиков SaaS-решений. А вот первые далеко не всегда понимают, что нужно сделать, чтобы их сервис удовлетворял запросам крупного клиента.
Этот текст как раз для разработчиков SaaS — тех, кто сделал приложение, несущее понятную ценность для бизнеса, и хочет, чтобы их сервис подошел средним и крупным компаниям. После его прочтения вы сможете оценить, насколько ваш продукт готов к внедрению в компаниях крупного бизнеса, и увидите ориентиры для его улучшения. Удобный гайд ждет вас под катом.
Добавьте управление доступом на основе ролей
Почему это важно?
В крупных компаниях руководители IT-подразделений и отделов информационной безопасности, как правило, уделяют большое внимание процессам предоставления доступа к корпоративным ресурсам. Разным сотрудникам и командам назначается только тот доступ, который им нужен для выполнения работы. При этом ответственные за доступ к ценным корпоративным данным руководствуются «принципом наименьших привилегий».
Для этого крупные компании используют ПО, которое автоматизирует процессы:
- выдачи идентификаторов,
- предоставления прав доступа,
- приостановки прав доступа,
- отзыва прав доступа, если сотрудник увольняется или больше не должен иметь доступ к определенным данным.
В эти процессы должно встраиваться и ваше SaaS-приложение.
Поэтому, чтобы быть готовым к использованию в крупных компаниях, ваш сервис должен предлагать управление доступом на основе ролей. Роль — это набор прав доступа, которые получает тот или иной пользователь.
Пример распределения ролей.
Какие функции должны быть в вашем SaaS-решении
— Сервисы для регистрации и управления настройками учетных записей.
— Возможность редактирования и создания собственных новых ролей и предоставления соответствующих прав.
— Интеграции с ПО, которое применяется в компании для управления доступом и идентификации.
Как решить задачу
Централизация управления доступами происходит при помощи специализированного ПО — IAM, или Identity Manager. Ваше приложение должно поддерживать соответствующий API для интеграции с IAM-системами ваших клиентов. Примеры таких систем:
- Active Directory Federal Service,
- Workspace ONE Access (ранее VMware Identity Manager),
- Google Workspace и пр.
Для реализации ролевой модели потребуется адаптировать приложение и интерфейс к так называемой матрице доступа на основе ролей. Так, каждый сотрудник вашего клиента должен иметь доступ к необходимым для работы функциям и информации. При этом для каждой роли интерфейс может незначительно отличаться — «подстраиваться» под ее задачи и доступы.
Например, у бухгалтера, заинтересованного в доступе к счетам-фактурам, будет доступ к платежным документам, но не будет — к настройкам приложения. У руководителя, просматривающего высокоуровневые отчеты, будет больший доступ к конфиденциальным данным, в отличие от рядового сотрудника. IT-администратор, в свою очередь, будет обладать уникальными правами управления учетными записями. Так, у руководителя таких прав может и не быть.
Добавление возможности контроля доступа, основанного на ролевой модели, — непростая задача, особенно для развитых SaaS c большим количеством возможностей. Поэтому часто такой функционал выносится в платные подписки для корпоративных клиентов.
Примеры реализации
Посмотрите, как реализовано управление доступом в популярных SaaS-сервисах, используемых в российских компаниях:
→ Мой склад
→ Miro
→ amoCRM
→ Bitrix24
Используйте технологию единого входа — Single Sign-On
Почему это важно?
По данным отчета «Cloud Report» компании Netscope, в среднем одна крупная западная компания используют более 1000 различных SaaS-приложений. Мы тоже посчитали число сервисов — в Selectel их более 150.
Использование устаревших способов входа в приложение — через логин и пароль — становится проблемой для пользователей. Сотрудникам приходится запоминать (или где-то хранить) данные всех аккаунтов, а администраторам — централизованно контролировать такие факторы, как сложность пароля, предоставление/отзыв доступа и так далее.
Чтобы избежать этих неудобств, используйте технологию единого входа, или Single Sign-On (SSO).
Как решить задачу
При SSO, после предварительных настроек со стороны SaaS-приложения и инфраструктуры заказчика, пользователь начинает использовать единую корпоративную учетную запись. При этом он не передает учетные данные и пароли поставщику каждого SaaS-приложения, используемого в компании.
Упрощенно это происходит так: сотрудник компании обращается к SaaS-приложению, а оно вместо отображения экрана входа отправляет запрос на идентификацию к IdP (identity provider), используемому в компании. В этом случае наше SaaS-приложение принимает роль поставщика услуг, устанавливая соединение с поставщиком удостоверений (LDAP, Active Directory) корпоративной сети заказчика. В роли IdP может выступать приложение, работающее на серверах компании, или еще одно SaaS-приложение.
Наиболее популярное open source-приложение, которое поможет реализовать SSO, — Keycloak. Это приложение для управления идентификацией и доступом со множеством интеграций и поддержкой стандартных протоколов SAML и openID.
Из платных есть и зарубежные, и российские решения. Из иностранных наиболее известны Okta, Auth0, OneLogin, а из отечественных — Blitz Identity Provider, которое включено в единый реестр российских программ.
Какие функции должны быть в вашем SaaS-решении
— Поддержка стандартных протоколов OpenID Connect, OAuth 2.0 и SAML.
— Возможность синхронизации данных корпоративных пользователей. В таком случае в личном кабинете SaaS-приложения отображается не только ФИО сотрудника, но и его должность и отдел.
— Поддержка многофакторной аутентификации для безопасной аутентификации пользователей.
Примеры реализации
Посмотрите, как это реализовано в популярных SaaS-приложениях:
→ Ispring
→ Miro
Добавьте пользовательские журналы аудита
Почему это важно?
Журналы аудита являются централизованным местом сохранения следов обо всей активности пользователей в приложении.
Важная задача специалистов по безопасности в крупных компаниях — контроль и мониторинг доступа к корпоративной информации. Но что происходит, если часть данных перемещается в ваш SaaS-продукт? Специалисты не могут использовать дополнительные агенты для мониторинга инфраструктуры и SaaS-приложения. Им приходится рассчитывать только на подробный журнал всей деятельности от имени учетных записей сотрудников, который предоставляет разработчик SaaS.
Журнал аудита может использоваться:
- для предотвращения подозрительной активности, если она контролируется,
- для исследования активности учетной записи во время расследования инцидентов.
Недостаточно регистрировать только системные события в инфраструктуре приложения и сохранять их, например, в Elasticsearch и подобных системах сбора и корреляции логов. Эта информация может быть полезной, но она предназначена в основном для диагностики проблем с производительностью приложений или безопасностью, которая находится в зоне ответственности поставщика SaaS.
Что ждут от журнала аудитов?
- должен регистрировать и сохранять следы взаимодействия каждого пользователя с системой,
- результаты должны быть доступными администраторам учетных записей и специалистам по безопасности компаний,
- лучшие журналы аудита полностью экспортируются, доступны через API и имеют хорошо задокументированный формат, чтобы клиенты могли использовать эти данные в корпоративных системах мониторинга ИБ.
Какие функции должны быть в вашем SaaS-решении
Поддержка неизменности записей (целостность)
Данные, записанные в журнале аудита, никогда не должны меняться. Информация об удаленных из приложения объектах и даже сама информация об удалении должны сохраняться в журнале. Внешние API (и администраторы клиента) должны иметь возможность только читать журнал аудита, а не записывать в него.
Синхронизация времени
Отдельные журналы аудита приложений, скорее всего, будут объединены с другими данными журнала аудита клиента, поэтому важно обеспечивать точность метки времени для каждого события. Используйте серверное время с регулярной синхронизацией с сервером NTP.
Возможность экспорта
Журналы аудита должны иметь возможность экспорта в формате CSV и в идеале доступны по API, чтобы их можно было выгрузить в SIEM, такую как MaxPatrol SIEM, Splunk и другие.
Настраиваемый срок хранения
По умолчанию журнал аудита должен храниться в течение полугода. Для некоторых задач — например, в банковской сфере — срок может составлять 1-3 года.
Автоматизация в предоставлении записей
Позаботьтесь о том, чтобы между сбором данных и предоставлением отчетов не было критических задержек. Они могут повлиять на время реагирования команды безопасности и негативно скажутся на оценке вашего продукта потенциальным клиентом. В идеале автоматизировать процесс предоставления данных, чтобы исключить ручные манипуляции со стороны администраторов.
Как решить задачу
Каждое SaaS-приложение уникально, поэтому и действия пользователей и администраторов, которые сохраняются для аудита, могут отличаться. Обычно регистрируются именно действия, произведенные над данными, и важный контекст — например, ошибки, когда пользователь пытался выполнить действие, но оно не было завершено.
Примеры событий, которые могут быть зарегистрированы в журнале аудита:
- действия пользователей приложений,
- события информационной безопасности,
- получение доступа,
- успешные и неудачные попытки входа в систему,
- выход из системы,
- изменение конфигурации аккаунта и попытки использования недоступных пользователю возможностей (например, удаления данных).
Поскольку ведение журнала, как правило, лишь дополнительный функционал приложений, разработчики зачастую используют уже готовые библиотеки или приложения. Примером таких готовых приложений может служить платформа управления журналами с открытым исходным кодом Graylog или широко распространенная и печально известная из-за проблем с безопасностью библиотека log4j.
Примеры реализации
Посмотрите, как компании реализуют журналы логов.
→ Miro
→ AmoCRM
Обеспечьте киберустойчивость и рассказывайте о ней
Почему важно?
Ежедневно ваши клиенты читают о последних утечках данных и не хотят пополнить список жертв. Большинство предприятий, прежде чем сделать выбор в пользу SaaS-приложения, предоставят вам как потенциальному поставщику ПО длинный опросник по соответствию безопасности.
Вопросы в этом документе охватывают такие темы, как:
- безопасность продуктов,
- физическую офисную безопасность и проверку сотрудников,
- безопасность офисной сети,
- непрерывность бизнеса,
- безопасность поставщиков, в том числе поставщиков инфраструктуры,
- вопросы юридической безопасности, такие как информация о конечных бенефициарах, и др.
Неготовность ответить о применяемых в компании инструментах и правилах для защиты информации напрямую повлияет на результат переговоров. CISO потенциального клиента, который отвечает за безопасность коммерческих данных и ПДн сотрудников и клиентов, не допустят использования вашего продукта.
Как решить задачу
Определите текущий уровень безопасности своего SaaS-приложения. Смоделируйте все возможные угрозы для его частей и инфраструктуры, рассмотрите различные векторы атак, найдите способы исключить или хотя бы минимизировать возможные риски.
Составьте оценку по следующим направлениям.
Безопасная эксплуатация продукта
— Большинство SaaS-приложений подразумевает удаленный доступ пользователей через интернет. Это значит, что к приложению могут получить доступ злоумышленники, используя незакрытые уязвимости.
Подумайте о создании многоуровневой защиты, которая будет включать сетевую защиту от DDoS-атак, межсетевые экраны, чтобы минимизировать открытие в интернет частей инфраструктуры, организуйте защиту серверов и баз данных.
— Многие SaaS-решения используют IaaS-инфраструктуру для обеспечения масштабируемости, безопасности и стабильности работы, Выясните у вашего провайдера, как происходит разграничение зон ответственности за безопасность и какие задачи уже решены. Например, в Selectel есть базовая защита от DDoS-атак, а инфраструктура соответствует 152-ФЗ.
Безопасная разработка продукта
Безопасность должна быть заложена в SaaS-приложение еще на этапе разработки программного обеспечения. Уязвимости, найденные в работающем приложении, исправлять намного дольше и дороже, чем если ту же уязвимость нашли бы на этапе разработки/тестирования.
Важно, чтобы разработчики имели необходимые инструменты для поиска ошибок (в виде случайно указанных паролей и секретов) и уязвимостей — как в коде приложения, так и в инфраструктурном коде (при использовании IaC).
Безопасность компании, сотрудников и подрядчиков
Каким бы безопасным ни было приложение, как бы тщательно ни проверялись новые релизы на отсутствие угроз, его поддержкой занимаются люди. Это значит, что необходимо уделить внимание безопасности сторонних приложений (например, в которых хранится код), с которыми работают ваши разработчики, и ноутбуков, с которых они подключаются — особенно при удаленной работе.
Постоянное обучение, многофакторная аутентификация и безопасный VPN-доступ — только базовые вещи которые должны быть реализованы. Никто не хочет, чтобы развитие бизнеса подвергалось риску, если кто-то из сотрудников по ошибке или незнанию кликнул на ссылку в фишинговом письме.
Теперь вы сможете рассказать своим клиентам о том, каким способом защищаете данные, многократно повысив доверие к вашему SaaS-приложению. Не забудьте уточнить про разграничение зон ответственности за безопасность. Сообщите, какие меры безопасности выполняются на вашей стороне, а о чем должен позаботиться ваш клиент. Будьте открыты, используйте свой сайт и базу знаний о продукте.
Примеры реализации
Посмотрите хорошие примеры того, как компании рассказывают о мерах обеспечения безопасности, которые у них реализованы:
→ Мегаплан
→ Bitrix24
→ AmoCRM
→ Мое дело
Продемонстрируйте соответствие требованиям законов и стандартов
Почему это важно?
Требования о соответствии международным стандартам в области ИБ и законам о защите персональных данных становятся все более строгими. И это напрямую касается компаний, которые предоставляют программное обеспечение как сервис.
Причина в том, что именно атаки на уровне приложения становятся причиной громких утечек данных. Регулирующие органы по всему миру создают более строгие правила в отношении безопасности ПО, а стоимость их несоблюдения резко возрастает. Так, штрафы за нарушение требований 152-ФЗ могут составлять до 18 млн рублей.
Критическую важность соответствие законам приобретает в том случае, если ваши целевые клиенты — компании из регулируемых отраслей, таких как медицина, финтех, и государственные компании. Такие клиенты относятся к рискам с повышенным вниманием и требуют обеспечения соответствия стандартам и нормам закона.
Какие законы и стандарты есть
Название закона/стандарта | Каким компаниям и приложениям важно соответствовать |
---|---|
152-ФЗ «О персональных данных» |
Для большинства, так как почти все компании и приложения собирают, обрабатывают и хранят персональные данные — самостоятельно или в интересах клиентов. |
Аттестация по 17 приказу ФСТЭК |
Если приложение взаимодействует с государственной информационной системой (ГИС) или само является ГИС. Если приложением будут пользоваться госкомпании или коммерческие компании с госучастием. |
AICPA SOC-2® | Если клиенты — коммерческие компании с высокими требованиями к поставщикам услуг. |
PCI DSS | Для тех, кто работает с платежными системами. |
ISO 27001 | Базовый стандарт в области управления информационной безопасности. |
ГОСТ 57 580 | Для финансовых организаций, таких как банки, платежные шлюзы, участники национальной платежной системы. |
GDPR | Для тех, кто обрабатывает персональные данные граждан Европейского союза или пребывающих на территории ЕС (например, туристов). |
Пример, как подтверждать соответствие тем или иным стандартам →
Имея соответствующие сертификаты, вы упрощаете потенциальным клиентам задачу по проверке вашего приложения. Не забудьте разместить информацию о compliance на сайте. Таким образом, у вас будет больше шансов привлечь крупных корпоративных клиентов
Как решить задачу
Вам нужен простой и масштабируемый способ оценки приложений по нескольким стандартам, чтобы достичь и продемонстрировать соответствие как регуляторам, так и требованиям клиентов.
Что предстоит сделать?
- Определите, каким стандартам должно соответствовать ваше приложение и инфраструктура, на которой оно работает. Это важно, чтобы не делать лишнего и реализовать только то, что необходимо для развития бизнеса.
— Выясните какие данные вы получаете и от кого (например, от пользователей или других компаний), где их обрабатываете и кому передаете.
— Изучите запросы потенциальных клиентов или клиентов, которые не выбрали вас из-за нерешенных задач в области compliance. Например, вы не смогли заполнить опросные листы о выполнении стандартов или процессов безопасности.
— Добавьте к этому общепринятые стандарты и требования для той отрасли, к которой относятся ваши клиенты. - Если вам нужно соответствовать нескольким стандартам, проверьте, есть ли пересечения в их требованиях. Так вы избежите очень похожих проверок и повторных доработок своего приложения.
- Чтобы использовать соответствие требованиям как конкурентное преимущество и повысить доверие клиентов к себе, нужно относиться к этому не как к разовой работе, а как к постоянному процессу, который выстраивают сотрудники с компетенциями на стыке:
— compliance — чтобы выяснить, какие именно задачи будут актуальны для соответствия выбранным стандартам,
— IT и защиты информации — чтобы, понимая устройство вашего приложения, реализовать на практике те или иные меры безопасности. - Если необходимые компетенции отсутствуют, а соответствия нужны уже сейчас, вам потребуется помощь сторонних компаний. Кроме того, подтвердить выполнение некоторых стандартов и выдать подтверждающий документ (аттестат, сертификат и пр.) зачастую могут только компании с соответствующей лицензией.
Как можно упростить задачу?
Если вы не транснациональная компания, а небольшая команда разработчиков, выполнить все эти сложные, непонятные и часто меняющиеся требования стандартов очень затратно. Есть несколько лайфхаков, которые могут упростить задачу:
- Вспомним о разграничении зон ответственности за безопасность при использовании облачных технологий. Некоторые задачи должен решить сам пользователь, передающий вам данные, — например, разграничить доступ и не добавлять в приложение данные, которые не разрешены в пользовательском соглашении и поручении на обработку персональных данных.
- Если для работы приложения вы используете IaaS-инфраструктуру от провайдера, то часть задач по безопасности и соответствию стандартам уже может быть решена на его стороне. Обратитесь к поставщику IT-инфраструктуры за консультацией, чтобы без усилий закрыть вопрос соответствия стандартам.
- Развернуть и поддерживать безопасное, соответствующей стандартами окружение для работы приложения можно силами аутсорса. Например, такую услугу предоставляет Selectel. Таким образом, часть задач можно делегировать сторонней компании и быстрее начать работать с компаниями, для которых важно соответствие стандартам.
Примеры реализации
Несколько компаний, которые не скрывают соответствие законам и стандартам:
→ Selectel
→ OnDoc
→ Мое дело
Подведем итоги
Итак, если у вас есть амбициозные планы по интеграции в большие компании, проверьте, реализованы ли у вас следующие пункты:
- Управление доступом на основе ролей.
- Технология единого входа (Single Sign-On).
- Ведение журналов аудита.
- Страница на сайте, посвященная безопасности SaaS.
- Соответствие требованиям законов и стандартов и информация об этом на сайте.
Я описал самые частые требования enterprise-компаний. Есть еще несколько пунктов из практики, о которых могу написать в следующей статье. Будет ли вам интересно? Пишите в комментариях.
Также поделитесь, какие требования предъявляли к вам клиенты? Совпадают ли они с описанными?
Комментарии (3)
bezkod
10.11.2022 20:43Не очень удачный российский пример приведен:
ПОЧЕМУ МЕГАПЛАН НЕЛЬЗЯ ВЗЛОМАТЬ?
После такого вопроса-утверждения доверия к компании в части ИБ становится только меньше.
LordDarklight
Мне кажется не совсем корректное предложение. Тут два нюанса:
Система может быть распределённой по разным регионам, находящимся в различных часовых поясах. Или даже если это не так - то разные приложения могут функционировать в разных часовых поясах (и это будет важно - когда логи будут сводиться в единую базу). Поэтому, правильнее приводить время к Гринвичу (UTC+00).
Пользователи могут работать из разны часовых поясов, и чтобы точнее определять момент события с точки зрения пользователя - нужно сохранять ещё и время клиента из сеанса пользователя. Ну, скажите - что не дело обсуждать с пользователем на камчатке, события приведённые к нулевому меридиану, а если таких пользователей в процессе было задействовано несколько и все в разных часовых поясах? Но тут сложности, когда пользователи с других часовых поясов работают через RDP - тут время клиента будет временем терминального сервера для всех. И вот тут уже вопрос как правильно поступать в таких случаях. Особенно всё усложняется, когда клиент одного и того же пользователя по факту может быть запущен на разных компьютерах, в разных часовых поясах (а такое вполне возможно, хотя навряд ли одновременно, но лично встречал когда то так, то эдак работал клиент; да хоть взять ещё и коммандировщиков - которые в разъездах по стране и клиент запущен у них на ноутбуках - хотя тут уже свои нюансы - часовой пояс в этом случае не все переведу, хотя он может и автоматически переводится, тем более если это смартфон/планшет с включённой синхронизацией по сети).
Работать с другого часового пояса пользователь может ещё и через Интернет или через VPN канал.
And4w Автор
Спасибо за комментарий который улучшает статью, и добавляет идей для читателей.
Временные метки, учет часовых поясов и различных форматов дат в журналах аудита - это важная тема особенно для приложений с распределенной инфраструктурой. В статье я не пытался описать настолько детальную реализацию функций журнала, а нюансы о которых Вы пишете точно важны и могут быть даже сложнее и здесь, на мой взгляд, для ответственных за разработку продукта применим итерационный подход - на первом этапе использовать простое добавление меток времени к событиям серверной части приложения, и дальнейшее улучшение о которых Вы пишете если это требуется клиентам (например, сотрудникам SOC при расследовании инцидентов).
Что касается сценария одновременного использования приложения одним пользователем о котором пишете - так это довольно частый сценарий когда пользователь одновременно подключается к SaaS приложению, например, с рабочего ноутбука и мобильного телефона.