Сегодня мы попытаемся понять в общих чертах, что такое HIPAA и как соответствовать этому стандарту в сфере программного обеспечения и инфраструктуры. Несмотря на то что это стандарт, с достаточно четкими техническими требованиями — его реализация может варьироваться от проекта к проекту, поэтому мы не будем излишне вдаваться в подробности.
Небольшая предыстория
У нас был опыт подготовки инфраструктуры для соответствия закону о мобильности и подотчетности медицинского страхования (Health Insurance Portability and Accountability Act или HIPAA), но тот стартап закрылся, не успев начаться. В другом проекте мы занимались разработкой инфраструктуры с нуля для прохождения Payment Card Industry Data Security Standard (PCI DSS). Несмотря на ворох проблем, в конечном счете проекту удалось пройти сертификацию. В обоих случаях есть пара схожих моментов, и они крайне мешали продуктивности и качеству при подготовке к аудиту.
Общие моменты
Итак, прежде чем перейдём непосредственно к HIPAA, давайте коротко разберем эти самые моменты:
Отсутствие юриста в команде на старте. Часто их участие откладывается до финальных стадий или их внимание сосредоточено на административных и процедурных аспектах, оставляя технические аспекты исключительно в руках инженеров. Возможно, это устраивает стейкхолдеров изначально, но исходя из собственного опыта могу сказать, что наличие в технической команде юриста, желательно с техническим образованием, на старте сильно улучшит качество подготовки и увеличит шанс на успешное прохождение аудита.
Отложенная безопасность. Частая проблема для проектов, и не только тех, которым нужен какой-то стандарт. При этом для имплементации некоторых аспектов по безопасности может потребоваться переписать с нуля приложение/сервис/продукт/инфраструктуру и т.д., а это, в свою очередь, может сильно затянуть подготовку и прохождение аудита.
Хотя эти вещи кажутся очевидными, они часто становятся приоритетными только непосредственно перед аудитом. Рекомендуется включать меры соответствия в архитектуру, начиная с этапа проектирования, и рассмотреть вопрос о найме консультанта, который может объяснить требования и помочь инженерам в их реализации. Такой подход поможет значительно сэкономить время и деньги.
HIPAA
Во-первых, давайте разберемся, что такое HIPAA. Это федеральный закон, принятый в Соединенных Штатах в 1996 году. Он был создан для установления руководящих принципов защиты личной медицинской информации, также известной как Защищенная медицинская информация (Protected Health Information или PHI). С распространением приложений для здоровья и появлением машинного обучения наблюдается постоянный приток новых онлайн-врачей и терапевтов, предлагающих свои услуги, связанные с различными проблемами со здоровьем. Благодаря HIPAA, персональная медицинская информация защищена от любых утечек и недобросовестных лиц. При таком сценарии пациенты могут самостоятельно контролировать информацию о себе.
HIPAA содержит правила, которые контролируют использование, передачу и раскрытие PHI поставщиками медицинских услуг, страховыми компаниями и другими организациями, участвующими в управлении этими данными. Закон обязывает организации принимать меры для защиты конфиденциальности, точности и доступности PHI, включая электронные PHI (ePHI).
HIPAA также предоставляет физическим лицам определенные права в отношении их данных, такие как возможность доступа к своим медицинским записям, запрос на внесение исправлений в эти записи и получение учета раскрытий своих PHI.
Если коротко, HIPAA значительно упростил обмен медицинской информацией между специализированными организациями, укрепив при этом защиту конфиденциальности.
ePHI
Очевидно, что основное внимание уделяется защите личных медицинских данных. Как упоминалось выше, ePHI — это просто PHI в электронной форме. HIPAA защищает 18 типов информации, в том числе:
ФИО;
Адреса;
Даты;
Номера автомобилей;
Телефонные номера;
Номера соцфонда, ИНН, ПИН и т.д.;
Любые номера счетов, страховых ордеров и т.д.;
Биометрические данные (отпечатки пальцев, фото сетчатки, запись голоса, данные о зубах, и фото ушей);
Фотографии лиц;
Электронная почта, IP-адреса или URLs связанные с пациентом.
Примером PHI может служить следующая информация:
Медицинские записи пациента. Любые записи в электронном виде, содержащие информацию, идентифицирующую пациента, историю болезни, результаты диагностических тестов и лечебных планов.
Страховые случаи. Записи в цифровом виде содержащие имена, диагнозы и процедуры лечения.
Рецепты на медикаменты. Электронные записи рецептов на медикаменты, содержащие имена пациентов, наименования, дозы и расписание приема лекарств.
Информация по счетам и оплатам. Цифровые записи счетов, счет-фактур и платежной информации, содержащие имена, страховую информацию и историю платежей.
Лабораторные отчеты и изображения. Цифровые копии диагностических тестов, отчетов, изображений, содержащих информацию, по которой можно идентифицировать пациента, результаты и любая диагностическая информация.
Данные по исследованиям. Результаты исследований, содержащие информацию, по которой можно идентифицировать пациента, результаты и истории исследований.
Информация о посещениях врачей и их расписании. Записи, содержащие информацию, которая может идентифицировать пациента, например, его имя, время посещения и имя врача или поставщика медицинских услуг.
Имейлы и история переписки. Копии писем или сообщений с других платформ, которые содержат медицинскую информацию.
Это примерный список, который может меняться для конкретного сервиса или приложения. Кроме того, некоторые данные могут быть классифицированы как PHI или перестать считаться PHI в ходе предоставления услуги в зависимости от наличия идентификаторов и возможности отслеживания отдельных лиц. Тут как раз и пригодится юрист.
Общая ответственность
Мы уже поговорили о HIPAA и информации, которую он призван защищать. Двигаясь вперед, мы приближаемся к теме поставщиков облачных услуг (Cloud Service Providers), сокращенно CSP. Каждый крупный CSP использует модель отношений, в которой обязанности по обеспечению безопасности распределяются между поставщиками и клиентами. Эта модель, называемая общей ответственностью (Shared Responsibilities), определяет, за какие меры безопасности отвечает CSP, а за какие — клиент.
Конкретное распределение ответственности может меняться от сервиса к сервису, и от конкретной модели оказания услуг — SaaS, PaaS, IaaS и от самого CSP. В общем виде Shared Responsibility выглядит так:
Обязанности CSP: Поставщики облачных услуг несут ответственность за безопасность базовой облачной инфраструктуры, такой как физические объекты ДЦ, сетевое оборудование и гипервизор, управляющий виртуальными машинами. CSP также несут ответственность за обеспечение доступности, надежности и масштабируемости предоставляемых ими облачных сервисов
Обязанности клиента: Клиенты облачных сервисов несут ответственность за безопасность приложений, данных и доступа пользователей к используемым ими облачным сервисам. Сюда входят такие задачи, как настройка файерволов, шифрование конфиденциальных данных, управление доступом пользователей и настройка систем обнаружения и предотвращения вторжений.
Проще говоря, CSP отвечает за безопасность облачной инфраструктуры, а клиент отвечает за защиту своих приложений и данных.
Знакомство с этой концепцией жизненно важно для правильного использования облачных сервисов и во избежание вводящих в заблуждение предположений о том, что облако по своей природе безопасно, независимо от предпринимаемых действий.
В контексте HIPAA совместная ответственность имеет решающее значение, поскольку правила устанавливают ограничения на использование сервисов для работы с ePHI. Такие услуги должны соответствовать требованиям HIPAA, но их использование само по себе не гарантирует, что ваш продукт также соответствует требованиям HIPAA без соответствующей настройки.
HIPAA-Eligible Services
У каждого CSP есть свой постоянно растущий список сервисов, который совместим с HIPAA. HIPAA-Eligible сервисы отвечают ряду требований и стандартов HIPAA в области безопасности, которые регулируют обращение с данными ePHI.
Важно понимать, что не все CSP или облачные сервисы соответствуют требованиям HIPAA. Если вы, например, как поставщик медицинских услуг при работе с ePHI используете облачную службу, которая не соответствует требованиям HIPAA, то можете столкнуться с риском нарушения правил HIPAA и понести штрафные санкции за несоблюдение правил. Поэтому важно тщательно проверять любые CSP или облачные сервисы, прежде чем использовать их для хранения или обработки ePHI.
Как мы заявляли ранее, соответствие требованиям HIPAA не обязательно означает, что ваша система или продукт полностью соответствуют требованиям HIPAA. Использование этих сервисов само по себе не обеспечивает автоматического соответствия требованиям HIPAA. Это предполагает общую ответственность, и это означает, что вы должны самостоятельно правильно настроить и управлять службой.
BAA
Мы приближаемся к концу и до сих пор не добрались до технических аспектов. Еще одним важным юридическим компонентом, необходимым для HIPAA, является концепция BAA (Business Associate Agreement), которая означает соглашение о деловом партнерстве. Как отмечалось ранее, данное соглашение подписывается в конкретном случае между нами и CSP, что гарантирует CSP должным образом защищает и хранит ePHI. А также обеспечивает при этом доступность и целостность этих данных. Эта гарантия предоставляется в виде письменного договора.
Также BAA подробно описывает обстоятельства, при которых CSP может получить доступ, использовать или раскрывать PHI, когда это необходимо. Кроме того, в BAA описываются условия, при которых соглашение может быть расторгнуто.
Если совсем коротко, то BAA — это юридический договор, в котором излагаются обязательства и стандарты того, как CSP обрабатывает ePHI от вашего имени. В конечном итоге эта информация будет храниться в их физической инфраструктуре и нужна для получения соответствия HIPAA.
Техническая реализация
Сейчас мы подходим к этапу технической реализации. Описание стандартов для обеспечения защиты конфиденциальности, целостности и доступности ePHI содержится в HIPAA Security Rule. Следовать данным стандартам и применять административные, физические и технические меры безопасности для защиты ePHI должны как сами организации здравоохранения, так и все их бизнес партнеры, включая CSP.
Очевидно, нас в первую очередь интересует Security Rule, поскольку реализация соответствующей инфраструктуры и продукта соответствующего HIPAA зависит от изложенных в нем мер безопасности. Те, кто знаком с HIPAA, знают, что в Security Rule отсутствуют четкие директивы чек-листов и детальных критериев, а многие меры безопасности описываются как уместные или разумные.
Безусловно, такой подход оправдан. Непрактично учитывать все возможные сценарии, в то время как более дальновидно установить общее направление, к которому нужно стремиться. Вы должны определить наиболее подходящие методы и стратегии для каждой ситуации и периода. Поскольку прогресс не стоит на месте, появляются новые стандарты безопасности и протоколы шифрования. Кроме того, данный стандарт отдает приоритет управлению рисками. Реестры рисков, их оценки, реакция на риски и планы на случай непредвиденных обстоятельств могут повлиять на техническую реализацию.
Но при этом существует ряд мер необходимых в любом случае:
Шифрование передаваемых данных (и Шифрование данных при хранении)
Контроль доступа и аутентификации
Целостность данных
Аудиторский контроль
Инфраструктура как код (IaC), (опционально).
Шифрование передаваемых данных и данных при хранении
Для прохождения HIPAA необходимо обеспечение защиты ePHI во время его передачи. Несмотря на наличие частной сети (VPC) в облаке, по-прежнему необходимо применять меры шифрования. Следовательно, необходимо использовать TLS на всех эндпоинтах всех сервисов, которые участвуют в передаче ePHI. На наш взгляд, полагаться на незашифрованные соединения неэффективно, и проще сделать шифрование по умолчанию везде. Это означает, что для конечных точек HTTP и балансировщиков следует либо отключить возможность подключаться без SSL, либо перенаправить их на HTTPS. Шифрование также необходимо использовать для хранилищ объектов, баз данных, служб очередей и других дополнительных служб и интеграций. Если вы используете Kubernetes для развертывания, масштабирования и управления контейнерными приложениями, вы можете реализовать сервисную сетку для шифрования связи между приложениями в кластере.
Рекомендуется использовать зашифрованные туннели, такие как VPN и IPSec, чтобы гарантировать защиту данных. Это особенно важно при предоставлении сотрудникам доступа к внутренним службам, которые имеют дело с ePHI или BAA, нуждающиеся в интеграции.
Шифрование данных при хранении (encryption at-rest) пока не является обязательным требованием HIPAA, его скорее предлагают рассматривать как дополнительную меру по безопасности, исходя из рисков. Однако конфиденциальная информация потенциально может храниться на сетевых дисках, объектных хранилищах (также распределенных по сети) и других типах хранилищ, над которыми нет физического контроля, что создает риск. По нашему мнению, включение шифрования при хранении также должно быть настройкой по умолчанию, независимо от HIPAA или других стандартов безопасности. Здесь предпочтительным протоколом является AES-256.
Таким образом, если по минимуму, для защиты данных при их передаче и хранении нам необходимо:
Все внешние эндпоинты должны быть защищены SSL без возможности использования голого HTTP.
Вся внутренняя коммуникация между приложениями и сервисами должна быть зашифрована.
То же самое касается и коммуникации через имейл, содержащим ePHI.
Соединения с базами данных, хранилищами объектов, службами очередей и подобными системами должны быть зашифрованы, а небезопасные соединения должны быть отключены.
При необходимости используйте безопасные туннели для подключения внешних интеграций или предоставления персоналу доступа к внутренним службам.
Все блочные хранилища в вашем облаке, хранилища объектов и другие системы хранения должны быть зашифрованы по умолчанию с использованием соответствующих настроек и политик.
Контроль доступа и аутентификации
Одним из жизненно важных элементов Security Rule для ePHI является контроль доступа к ePHI, который играет важную роль в обеспечении доступа, чтения или изменения защищенной информации только уполномоченными лицами. Доступ к системным компонентам, ресурсам и информации регулируется посредством аутентификации и авторизации.
При аутентификации мы проверяем личность человека, устройства или приложения с помощью логина и пароля, а также с помощью дополнительных мер, таких как многофакторная аутентификация, биометрические данные, сертификаты и другие методы. Когда дело доходит до авторизации, мы используем RBAC, ACLs, IAM и другие подходы, чтобы определить уровень доступа для аутентифицированного пользователя.
Внедрив соответствующие элементы управления доступом, группы и организации могут эффективно применять принцип наименьших привилегий (least-privileges). Этот принцип гарантирует, что пользователям предоставляется только минимальный набор разрешений, необходимый для выполнения требуемых задач, что сводит к минимуму риск несанкционированного доступа или утечки данных.
На сетевом уровне также важно придерживаться принципа наименьших привилегий. Это означает, что все службы и ресурсы инфраструктуры должны работать в частных подсетях, за исключением общедоступных балансировщиков нагрузки. Доступ между службами и приложениями в частной сети должен быть ограничен с помощью групп безопасности, NACL, брандмауэров и сетевых политик.
Целостность данных
Поскольку ePHI является наиболее важным аспектом HIPAA, то нам необходимо прикладывать максимум усилий для обеспечения целостности этих данных. Хотя строгий контроль доступа, аудит событий и шифрование могут решить эту проблему, необходимо предпринять несколько дополнительных шагов.
Создание плана резервного копирования и восстановления данных чрезвычайно важно, поскольку он гарантирует, что в случае повреждения данных информация может быть возвращена в исходное состояние, а любые несанкционированные изменения или удаления могут быть восстановлены. Рекомендуется автоматизация этого процесса, которая должна сопровождаться строгим контролем доступа и шифрованием. Кроме того, необходимо проводить регулярные обучающие мероприятия, чтобы обеспечить грамотное восстановление данных. И только тогда можно будет утверждать, что система бэкапов работает.
Помимо шифрования, для валидации и гарантии целостности данных можно использовать чексуммы или цифровые подписи, по которым можно отслеживать подлинность данных или любых внесенных в них изменений. Для этой цели также могут быть использованы технологии блокчейн.
Еще один подход, который может улучшить целостность данных, — это версионирование (software versioning). Это помогает вести историю изменений, а также предоставляет возможность отката данных к предыдущим версиям, если произошли неавторизованные изменения или данные были испорчены.
Аудиторский контроль
Этот компонент Security Rule не менее важен. С одной стороны, он служит процедурным, с другой программным механизмом регистрации и проверки действий в информационных системах, содержащих или использующих ePHI. Он помогает организациям отслеживать использование ePHI, выявлять потенциальные инциденты безопасности и предоставлять ценную информацию для расследований или аудитов.
Аудит является важнейшим компонентом не только HIPAA, но и в большинстве других стандартов безопасности. Без него сертификат соответствия получить невозможно. Его отсутствие — признак слепой и бесконтрольной работы системы, что недопустимо. Аудит также требует контроля доступа, целостности данных, хранения и мониторинга. Поэтому в крупных инфраструктурах этот компонент выделяется и развивается самостоятельно.
Кроме этого, аудит включает в себя сбор логов, активностей и событий, связанных с действиями в ePHI, такими как доступ пользователей, изменение или удаление данных, а также различные системные и сервисные события. А поскольку доступ к данным потенциально можно получить не только через предлагаемые пользователю приложения, то логированию подлежит также сетевая активность и активность внутри инфраструктурных аккаунтов.
Сейчас CSP предлагают большой набор средств для наблюдения за всеми событиями и обращениями к ресурсам и данным, а также access логи сервисов и даже VPC flow logs.
Кроме того, могут потребоваться IDS системы, чтобы отслеживать хосты или узлы на предмет несанкционированных изменений файлов конфигурации библиотек или программного кода, что также может поставить под угрозу безопасность ePHI.
Собрав и предоставив всю информацию, следующим шагом будет создание системы для анализа событий, отчетности, моделирования и мониторинга. В зависимости от количества источников, архитектуры и размера можно воспользоваться как предлагаемыми CSP сервисами, так и настроить свой SEIM, куда будут стекаться все события со всех источников для дальнейшего управления.
В задачу также будет входить обеспечение целостности этих данных на протяжении всего срока их хранения с помощью таких методов, как управление версиями, контроль доступа, шифрование и резервное копирование.
Инфраструктура как код
Хотя требование инфраструктура как код (IaC) отсутствует в HIPAA Security Rule, его применение усилит контроль над изменениями и поможет значительно снизить риски возникновения ошибок в конфигурациях. Кроме того, использование инструментов и шаблонов IaC поможет в реализации необходимых правил и политик, гарантируя, что все ресурсы инфраструктуры выделяются и настраиваются последовательно в соответствии с установленными стандартами безопасности. В конечном итоге эти меры снижают вероятность ошибок или несоответствий в настройках, которые могут привести к уязвимостям в системе безопасности.
IaC позволяет ИТ-командам управлять ресурсами инфраструктуры как кодом. Это обеспечивает контроль версий и возможности аудита для всех изменений, внесенных в среду. Такое отслеживание, проверка и управление конфигурациями инфраструктуры являются важнейшими требованиями Security Rule.
Кроме того, IaC позволяет тестировать изменения в конфигурации инфраструктуры перед развертыванием в производственной среде. Это позволяет выявлять и устранять потенциальные проблемы безопасности до их фактического возникновения. А поскольку это as Code, его можно интегрировать в CI/CD для автоматизированного тестирования и интеграции кода, сводя к минимуму влияние человеческого фактора.
Заключение
Хотя соблюдение требований HIPAA не вызывает затруднений, его реализация может оказаться высокотехнологичной и монотонной задачей. Целесообразно обратиться за помощью к знающим людям, так как последствия несоблюдения могут привести к значительным штрафам.