Как обеспечить безопасность данных (медицинские анализы)?

Question

[Дмитрий Грабко]

Есть сайт клиники на битриксе с личным кабинетом. Планируется добавление хранения данных анализов. Сами результаты анализов предоставляет сторонняя лаборатория, данные будут получаться через их API. Результаты будут храниться в ЛК пользователя. Беспокоит само хранение анализов у себя на сайте.

До этого такой тип данных обрабатывать не приходилось.

Что сейчас планируется:

• Авторизация по СМС (что не спасет от получения админских прав)
  
• Получение данных анализа только по запросу из ЛК, чтобы не хранить их просто так у себя на сайте
  
• Сделать периодическую очистку данных, т.к. оборот небольшой и пользователь при необходимости просто запросит данные снова
  
• Сделать отдельный скрипт для анализа всплеска запросов к API (больше n в минуту/час/день) и отрубать получение данных при аномалиях
  

Что еще стоит предусмотреть, изучить.Может что то лишнее?

Comments

[Adamos]

Если ваша лаборатория готова предоставить данные заново после того, как вы удалили их у себя - какой смысл вообще их хранить у вас? Чтобы было удобнее взломавшему ваш Битрикс и слившему вашу базу? Или чтобы легче вас было нагнуть по закону о ПД?

[Drno]

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

[Adamos]

Drno, они уже хранятся "на отдельном серваке" - у лаборатории. Причин дублировать не озвучено.

[Дмитрий Грабко]

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

[Adamos]

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

[Александр Маджугин]

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

[Александр Маджугин]

В целом решение кажется правильным с дополнением Adamos про "вообще не надо хранить у себя" - это выглядит логично.
А все рассуждения про то что если сайт взломают...
Не взламывают битрикс, если:
1 Нет простых паролей
2 Сам не оставил нигде бэкдоров, в т.ч. restore.php забытый в корне
3 Удалил все неиспользуемые модули (привет модуль vote!)
4 Вовремя обновляешься
Это 4 простых правила.

[Adamos]

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

[Дмитрий Грабко]

Александр Маджугин, остается человеческий фактор, что кто-то изнутри начнет сливать данные. Тогда мучает вопрос стоит ли запариваться со всем перечисленным в вопросе

[Александр Маджугин]

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

[Александр Маджугин]

Дмитрий Грабко, или использует экстрасенсов боевых...
Ну можно придумать еще кучу угроз. Где-то стоит поставить точку в паранойе своей. Вон Гемотест продолжает себе работать. Не разорился ;)
Ясно что не хочется повторения.

Ну ок - давайте подумаем - "кто-то внутри начнет сливать". А как? Уведёт вашу авторизацию каким-то образом, в общем случае, имея доступ к сайту? Ну да - такое возможно и не ясно как от этого защититься. Придумайте лимит на стороне лаборатории, чтобы история не могла стать массовой. Добавьте на стороне лабы фильтрацию по IP. Что-то такое.

[Adamos]

Александр Маджугин, у моего подопечного сайта он тоже всю жизнь отключен, только вот три дня назад вычищал с сайта заразу. Например, картинку-троян из /upload/main.

[Александр Маджугин]

Adamos, как залили?

[Adamos]

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

[Vladislav]

Это всё нужно решать совместно с СБ клиента или своей если есть. Я как-то спрашивал об ответственности за подобные вопросы сотрудников СБ - всё решается согалсованным требованиями и регламентами, закупками сертифицированных ПО, проведением аудитов и подписью ГД(своего или клиента) о том, что "провели аудит, получили рекомендации, привели в соответствие с регламентом". на 100% нельзя гарантировать а значит и нести ответстенность на 100% тоже не получится.

А технически, как идея, на сайте "хранить" только уведомления о том что анализы готовы, даты и логи. Посмотрите как у инвитро сделано (никакого отношения к ним не имею если что) - у них это вынесено в отдельный сервис с отдельной, насколько я помню, регистрацией. Можно ещё обезличить информацию в БД с анализами в этом сервисе и хранить вместо ФИО какой-нибудь свой IDи мапить их с ФИО клиента только на основном сайте, отдельно от БД с анализами. Ещё такой вариант разделения возможно будет дешевле т.к. не нужно будет весь сайт "приводить в соответствие с реглаинтом".

Answer 1

[Maksim Herasim]

1. До запуска прод.контура тестирование независимыми экспертами. В отчете будет вся необходимая информация которую можно будет изучить и закрыть найденные уязвимости.
2. Если данные можно получать из внешнего источника, тогда нет смысла их хранить в своей базе, получайте данные по запросу пользователя. С подтверждением по одноразовому коду из СМС или генератору.
3. Если данные всё таки хранятся в вашей базе - хранить данные в зашифрованном виде, каждый пользователь должен иметь возмонжость расшифровать данные только своим ключом.
4. Контроль доступа к этим данным с логирование. Чтобы можно было понять, кто, когда и какие данные получал. В идеале как вы описали с мониторингом всплесков.
5. Постоянно обновлять систему. Если есть вариант написать самописную систему который во фронте будет отдавать только html, чтобы не было возможностей на стороне клиента запускать уязвимости, тогда лучше поступить так

Comments

[Adamos]

Еще неплохо бы завести отдел ИБ человек из пяти, чтобы приглядывать за администратором сайта и админом (особенно если это один человек).

[Maksim Herasim]

Adamos, С ружьем у виска )

Answer 2

[CityCat4]

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