Информационная безопасность в BetaOnline: как мы работаем с данными и обеспечиваем их защиту
СТАТЬИ
29.08.2021
В июле 2021 в свободном доступе оказались персональные данные нескольких тысяч человек, собранные крупным сервисом автоматизации подбора сотрудников. В апреле этого же года на теневых форумах появилось объявление о продаже данных привилегированных клиентов одного из ведущих банков — с их полными именами, контактами и номерами счетов. К утечкам из соцсетей и мессенджеров, кажется, и вовсе уже все привыкли.
История стара как мир: если где-то есть товар, который кто-то готов купить, то кто-то обязательно попытается его продать, даже если для этого нужно нарушить закон и моральные принципы. А персональные данные — дорогой актив, поэтому охота за ним идет постоянно. Весь вопрос в том, насколько серьезно подготовиться к атакам и защитить данные, с которыми вы работаете.
В новостях, например, появляются удивительные случаи, когда в буквальном смысле в лесу и на свалках находят оригинальные банковские документы. Говорить о защите данных в таких ситуациях не приходится. Но все-таки большинство компаний об этом думают — как минимум потому, что такая обязанность закреплена в Федеральном законе №152. Однако усилия прилагают разные.
Выступая оператором персональных данных, наша компания всегда придавала их защите первостепенное значение. О том, как организована информационная безопасность в нашем бизнес-процессе вообще и ИТ-системе в частности, — рассказывает Сергей Шапоров, IT-директор BetaOnline.
История стара как мир: если где-то есть товар, который кто-то готов купить, то кто-то обязательно попытается его продать, даже если для этого нужно нарушить закон и моральные принципы. А персональные данные — дорогой актив, поэтому охота за ним идет постоянно. Весь вопрос в том, насколько серьезно подготовиться к атакам и защитить данные, с которыми вы работаете.
В новостях, например, появляются удивительные случаи, когда в буквальном смысле в лесу и на свалках находят оригинальные банковские документы. Говорить о защите данных в таких ситуациях не приходится. Но все-таки большинство компаний об этом думают — как минимум потому, что такая обязанность закреплена в Федеральном законе №152. Однако усилия прилагают разные.
Выступая оператором персональных данных, наша компания всегда придавала их защите первостепенное значение. О том, как организована информационная безопасность в нашем бизнес-процессе вообще и ИТ-системе в частности, — рассказывает Сергей Шапоров, IT-директор BetaOnline.
Безопасность получения и передачи данных
Все коммуникации с внешним миром — будь то получение персональных данных с посадочных страниц или их передача в ATS (Applicant Tracking System) наших клиентов — всегда ведутся по защищенному HTTPS-каналу.
Коммуникация наших сервисов с серверами баз данных также происходит исключительно по зашифрованным каналам — несмотря на то, что эти запросы проходят только во внутренней сети, шифрование идет даже там.
Система BetaOnline имеет микросервисную архитектуру, в которой реализована конвейерная обработка данных. Это позволяет не хранить все данные в одной базе, как в классическом подходе, а передавать сервисам только те данные, которые нужны им для выполнения конкретных функций.
Проще говоря, данные разбросаны по базам разных сервисов — а значит, чтобы получить из них какую-либо информацию, представляющую бизнес-ценность, необходимо знать, откуда ее брать и как соединять. При этом для общения между собой сервисы и микросервисы также используют асимметричный стандарт шифрования x.509.
Чтобы другие компании могли безопасно получать персональные данные, мы используем собственный специально разработанный OpenAPI — такой подход позволяет нам полностью контролировать все вопросы безопасности, что невозможно при использовании чужого API.
В своем OpenAPI мы используем расширенный стандарт JWT, который имеет несколько слоев дополнительной защиты. С его помощью система понимает, кому и к каким данным можно предоставлять доступ. Оценить уровень защищенности BetaOnline OpenAPI позволяет тот факт, что он успешно проходит проверку служб безопасности клиентов — крупных компаний финансового сектора.
Все коммуникации с внешним миром — будь то получение персональных данных с посадочных страниц или их передача в ATS (Applicant Tracking System) наших клиентов — всегда ведутся по защищенному HTTPS-каналу.
Коммуникация наших сервисов с серверами баз данных также происходит исключительно по зашифрованным каналам — несмотря на то, что эти запросы проходят только во внутренней сети, шифрование идет даже там.
Система BetaOnline имеет микросервисную архитектуру, в которой реализована конвейерная обработка данных. Это позволяет не хранить все данные в одной базе, как в классическом подходе, а передавать сервисам только те данные, которые нужны им для выполнения конкретных функций.
Проще говоря, данные разбросаны по базам разных сервисов — а значит, чтобы получить из них какую-либо информацию, представляющую бизнес-ценность, необходимо знать, откуда ее брать и как соединять. При этом для общения между собой сервисы и микросервисы также используют асимметричный стандарт шифрования x.509.
Чтобы другие компании могли безопасно получать персональные данные, мы используем собственный специально разработанный OpenAPI — такой подход позволяет нам полностью контролировать все вопросы безопасности, что невозможно при использовании чужого API.
В своем OpenAPI мы используем расширенный стандарт JWT, который имеет несколько слоев дополнительной защиты. С его помощью система понимает, кому и к каким данным можно предоставлять доступ. Оценить уровень защищенности BetaOnline OpenAPI позволяет тот факт, что он успешно проходит проверку служб безопасности клиентов — крупных компаний финансового сектора.
Как устроена безопасность BetaOnline OpenAPI: уровни защиты
Компьютеры рекрутеров клиентов, находящиеся в DMZ (“демилитаризованной зоне”, т.е. имеющие доступ в Интернет и к внутренней корпоративной сети), могут получить токен JWT, используя логин и пароль, которые хранятся на сервере во внутренней сети клиента.
Наш OpenAPI спроектирован так, чтобы имелась возможность реализовать схему работы, при которой рекрутеры не знают логина и пароля от BetaOnline OpenAPI, а их компьютеры хранят логин и пароль в защищенной памяти процесса очень короткий промежуток времени.
Схема выглядит так: компьютеры из DMZ получают логин и пароль — с ними проходят аутентификацию на нашем сервере — получают JWT-токен и далее совершают все обращения только с ним. Логин и пароль могут быть удалены с рабочей станции рекрутера — они больше ни к чему там.
А что если украсть токен с компьютера рекрутера? Мы предусмотрели такой сценарий, поэтому заложили внутрь токена надежно зашифрованный fingerprint — параметры компьютера, с которого делается запрос. Получая запрос, OpenAPI сравнивает отправленный fingerprint с тем, что был передан при аутентификации и хранится в зашифрованном виде в JWT. Если они не совпадают, злоумышленник увидит не данные, а ошибку. Поэтому сама попытка украсть токен доступа не имеет смысла — без fingerprint его невозможно использовать.
Еще один метод охотников за данными — кража ключей, логинов и паролей, которые люди нередко передают друг другу через открытые каналы связи (по электронной почте, в мессенджерах и т.д.). Чтобы устранить и этот риск, первый пароль, который мы выдаем клиенту, может быть использован только для установки нового пароля через OpenAPI — с ним нельзя аутентифицироваться в системе BetaOnline. Получив первоначальный пароль, специалист передает его в систему, которая работает с BetaOnline OpenAPI, та производит автоматическую генерацию нового пароля, обращается на OpenAPI и меняет его. После этого никто, кроме самой системы, не будет знать пароль для доступа к BetaOnline OpenAPI. И только после смены пароля внешняя система сможет получать JWT токены, которые позволяют работать с персональными данными с наших серверов.
Так мы можем гарантировать, что никому из наших сотрудников не известны действующие логины и пароли доступа к OpenAPI.
Конечно, все пароли — и заданные нами, и созданные клиентскими системами — хранятся в зашифрованном виде. Алгоритм хеширования SHA512, который практически невозможно расшифровать на текущем уровне технологий, делает бессмысленным похищение базы с логинами, паролями или JWT.
Компьютеры рекрутеров клиентов, находящиеся в DMZ (“демилитаризованной зоне”, т.е. имеющие доступ в Интернет и к внутренней корпоративной сети), могут получить токен JWT, используя логин и пароль, которые хранятся на сервере во внутренней сети клиента.
Наш OpenAPI спроектирован так, чтобы имелась возможность реализовать схему работы, при которой рекрутеры не знают логина и пароля от BetaOnline OpenAPI, а их компьютеры хранят логин и пароль в защищенной памяти процесса очень короткий промежуток времени.
Схема выглядит так: компьютеры из DMZ получают логин и пароль — с ними проходят аутентификацию на нашем сервере — получают JWT-токен и далее совершают все обращения только с ним. Логин и пароль могут быть удалены с рабочей станции рекрутера — они больше ни к чему там.
А что если украсть токен с компьютера рекрутера? Мы предусмотрели такой сценарий, поэтому заложили внутрь токена надежно зашифрованный fingerprint — параметры компьютера, с которого делается запрос. Получая запрос, OpenAPI сравнивает отправленный fingerprint с тем, что был передан при аутентификации и хранится в зашифрованном виде в JWT. Если они не совпадают, злоумышленник увидит не данные, а ошибку. Поэтому сама попытка украсть токен доступа не имеет смысла — без fingerprint его невозможно использовать.
Еще один метод охотников за данными — кража ключей, логинов и паролей, которые люди нередко передают друг другу через открытые каналы связи (по электронной почте, в мессенджерах и т.д.). Чтобы устранить и этот риск, первый пароль, который мы выдаем клиенту, может быть использован только для установки нового пароля через OpenAPI — с ним нельзя аутентифицироваться в системе BetaOnline. Получив первоначальный пароль, специалист передает его в систему, которая работает с BetaOnline OpenAPI, та производит автоматическую генерацию нового пароля, обращается на OpenAPI и меняет его. После этого никто, кроме самой системы, не будет знать пароль для доступа к BetaOnline OpenAPI. И только после смены пароля внешняя система сможет получать JWT токены, которые позволяют работать с персональными данными с наших серверов.
Так мы можем гарантировать, что никому из наших сотрудников не известны действующие логины и пароли доступа к OpenAPI.
Конечно, все пароли — и заданные нами, и созданные клиентскими системами — хранятся в зашифрованном виде. Алгоритм хеширования SHA512, который практически невозможно расшифровать на текущем уровне технологий, делает бессмысленным похищение базы с логинами, паролями или JWT.
Базы данных: безопасность хранения и доступа
Как уже говорилось, благодаря конвейерной обработке данные хранятся не в едином месте, а в разных базах. Резервные копии этих баз данных мы шифруем при помощи алгоритма AES-256, причем ключ для расшифровки есть только у двух человек в нашей компании. Вот почему и с этой стороны не удастся получить несанкционированный доступ к данным: даже украв резервные копии баз данных, злоумышленник не сможет их расшифровать.
К production-серверам есть доступ только у тех, кто по долгу службы занимается их обслуживанием. При разработке и тестировании нового функционала мы используем специально разработанный тестовый стенд, который содержит сгенерированные данные, — даже наш техотдел не имеет доступа к реальным персональным данным, которые мы храним.
Сотрудники бизнес-подразделений BetaOnline также не имеют доступа к персональным данным, если этого не требует их рабочий процесс. А со стороны тех, чьи роли в проектах предполагают работу с данными, все действия с ними записываются в логах и могут быть в любой момент проверены.
Интересный факт о безопасности из нашей истории. Год назад система BetaOnline подверглась внезапному тестированию безопасности со стороны “белого хакера” (правильно называть его пентестер). Все, что ему удалось достать, — это незначительная информация типа названия ПО, которое мы используем. А в этом году мы планируем уже сами обратиться за услугами пентестера — чтобы быть уверенным, что наши контуры безопасности надежно защищают ценные для людей и бизнеса данные.
За нарушение требований федерального закона «О персональных данных» предусмотрена ответственность. Утечка конфиденциальных данных может нанести компании репутационный и материальный ущерб.
Как уже говорилось, благодаря конвейерной обработке данные хранятся не в едином месте, а в разных базах. Резервные копии этих баз данных мы шифруем при помощи алгоритма AES-256, причем ключ для расшифровки есть только у двух человек в нашей компании. Вот почему и с этой стороны не удастся получить несанкционированный доступ к данным: даже украв резервные копии баз данных, злоумышленник не сможет их расшифровать.
К production-серверам есть доступ только у тех, кто по долгу службы занимается их обслуживанием. При разработке и тестировании нового функционала мы используем специально разработанный тестовый стенд, который содержит сгенерированные данные, — даже наш техотдел не имеет доступа к реальным персональным данным, которые мы храним.
Сотрудники бизнес-подразделений BetaOnline также не имеют доступа к персональным данным, если этого не требует их рабочий процесс. А со стороны тех, чьи роли в проектах предполагают работу с данными, все действия с ними записываются в логах и могут быть в любой момент проверены.
Интересный факт о безопасности из нашей истории. Год назад система BetaOnline подверглась внезапному тестированию безопасности со стороны “белого хакера” (правильно называть его пентестер). Все, что ему удалось достать, — это незначительная информация типа названия ПО, которое мы используем. А в этом году мы планируем уже сами обратиться за услугами пентестера — чтобы быть уверенным, что наши контуры безопасности надежно защищают ценные для людей и бизнеса данные.
За нарушение требований федерального закона «О персональных данных» предусмотрена ответственность. Утечка конфиденциальных данных может нанести компании репутационный и материальный ущерб.