Содержание


Конфиденциальность и безопасность данных пациентов в облаке

Ответственность поставщиков и потребителей облачных сервисов согласно законодательству США

Примечание редактора, 16 апреля 2013г. Эта статья, впервые опубликованная в 2012 году, дополнена информацией, связанной с изменениями в законе HIPAA, вступившими в силу в январе 2013 года .

Новые технологии, от электронной медицинской документации и медицинских устройств до мобильных и Web-приложений, позволяют врачам улучшать состояние здоровья пациентов и спасать жизни. Врачам эти технологии позволяют собирать больше информации для изучения историй болезни пациентов. Эти технологии и связанные с ними данные постоянно взаимодействуют, обмениваясь информацией о здоровье с помощью все более сложных систем, что увеличивает риски и уязвимости. Врачи больше не являются единственными хранителями конфиденциальной информации о здоровье. Сегодня, например, лица, управляющие хранением данных, также имеют доступ к этой информации и, таким образом, несут ответственность за ее сохранность.

Осознавая уязвимость информации о здоровье, правительство США приняло законы Health Information Portability and Accountability Act (HIPAA) в 1996 году и Health Information Technology for Economic and Clinical Health (HITECH) Act в 2003 году (см. раздел Ресурсы). Эти законы требуют от организаций, имеющих дело с информацией о здоровье, выполнения определенных мероприятий по обеспечению конфиденциальности и безопасности, а также информирования пациентов в случае, когда конфиденциальность и безопасность их личных данных находится под угрозой.

В условиях, когда потребители переходят на облачные сервисы, понимание этих стандартов и требование строгого их соблюдения становится основой ответственного поведения организации и доверия пациентов, сообщающих конфиденциальные подробности о своем здоровье. Данная статья предоставляет основу для решения вопросов, связанных с облачными сервисами, давая общее представление о HIPAA и HITECH, а также о том, к кому применяются эти законы, правила и инструкции. Затем в статье рассматриваются вопросы управления данными, доступа, целостности, доступности, общих многопользовательских сред, готовности к инцидентам и реагирования на них, а также безопасности данных, чтобы предотвратить несоблюдение требований HIPAA и HITECH как потребителями, так и поставщиками облачных сервисов.

Законы HIPAA и HITECH Act

Говоря о HIPAA, часто упускают из вида нюансы этого сложного комплекса законов, правил и инструкций. Зачастую конфиденциальность и безопасность используются просто как модные термины без учета нюансов HIPAA и HITECH, что может исказить смысл требований этих законов.

HIPAA

HIPAA представляет собой набор специальных стандартов конфиденциальности и безопасности для определенной информации о здоровье, которые известны как HIPAA Privacy Rule (стандарт конфиденциальности) и HIPAA Security Rule (стандарт безопасности) соответственно. Под действие стандартов HIPAA подпадают медицинские организации, такие как медицинские учреждения, страховые компании и центры медицинских расчетов.

На Web-сайте Министерства здравоохранения и социальных служб США (HHS) говорится, что (см. раздел Ресурсы):

HIPAA Privacy Rule обеспечивает федеральную защиту персональной информации о здоровье, используемой медицинскими организациями, и предоставляет пациентам совокупность прав в отношении этой информации. В то же время Privacy Rule позволяет раскрывать персональную информацию о здоровье, необходимую для лечения пациентов и использования в других важных целях.

В свою очередь HIPAA Security Rule "определяет ряд административных, физических и технических мероприятий, которые должны выполнять медицинские организации для обеспечения конфиденциальности, целостности и доступности электронной охраняемой информации о здоровье".

HITECH Act

HITECH Act потребовал от министра здравоохранения США расширить область действия стандартов HIPAA Security Rule и Privacy Rule и увеличить штрафы за нарушения HIPAA. Ранее юрисдикция Управления по гражданским правам (OCR) министерства HHS в части утечек частной информации распространялась только на медицинские организации. HITECH Act распространил стандарты HIPAA Privacy Rule и Security Rule на бизнес-партнеров (BA) – физических и юридических лиц, выполняющих определенные функции или действия, которые связаны с использованием или разглашением PHI от имени (или при предоставлении услуг) медицинской организации. Бизнес-партнеры часто предоставляют такие услуги как обработка и администрирование претензий, анализ данных, оценка использования и управление. Поставщик облака, в котором PHI хранится непосредственно от имени медицинской организации или косвенно через ее бизнес-партнера, теперь тоже считается бизнес-партнером.

Правила Omnibus Rules

В январе 2013 года управление OCR опубликовало окончательную редакцию документа Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Nondiscrimination Act ("Изменения в правилах обеспечения неприкосновенности частной жизни, безопасности, соблюдения требований и извещения об утечках, принятых в соответствии с Законом об использовании медицинских информационных технологий в клинической и экономической деятельности и Законом о запрете генетической дискриминации"), а также документа Other Modifications to the HIPAA Rules ("Прочие изменения в правилах HIPAA") – так называемых объединенных правил Omnibus Rules (см. раздел Ресурсы). Эти правила вносят изменения в определение понятия "бизнес-партнер", повышают безопасность и конфиденциальность PHI, возлагают прямую ответственность на бизнес-партнеров, меняют пороговое значение ущерба в правиле Breach Notification Rule и уточняют содержание соглашения с бизнес-партнерами. В обнародованных окончательных правилах наиболее важным моментом для поставщиков и потребителей облачных сервисов является то, что для обеспечения соблюдения закона юрисдикция OCR распространяется на бизнес-партнеров и их субподрядчиков.

В правилах Omnibus Rules существенно изменено определение бизнес-партнера. Теперь в них указано, что субподрядчики бизнес-партнеров считаются лицами, действующими от их имени. Субподрядчики – это лица, которым бизнес-партнер делегирует выполнение функции, работы или услуги для организации, подпадающей под действие HIPAA, или другого бизнес-партнера. По существу, субподрядчики – это бизнес-партнеры бизнес-партнеров и дальше по цепочке до организаций, имеющих дело с информацией PHI.

Если в процессе бизнес-отношений с медицинской организацией или ее бизнес-партнером организация создает, получает, обслуживает или передает PHI, значит она является бизнес-партнером. Слово "поддерживает" имеет первостепенное значение в новом правиле, особенно для поставщиков облачных сервисов.

Поставщики облачных сервисов как бизнес-партнеры

Поставщики облачных сервисов занимают уникальное место среди бизнес-партнеров, которым доверена EPHI. Когда принимался HIPAA, понятие "облако" не существовало, и, вероятно, не могло быть предсказано. Медицинские организации и другие бизнес-партнеры для хранения информации о здоровье все чаще выбирают облако. Наиболее распространенными причинами этого являются экономия средств, управление ресурсами хранения данных, стабильность платформы, доступность ресурсов, резервное копирование и восстановление, а также уменьшение объема ИТ-работы по обслуживанию (см. раздел Ресурсы). Однако когда EPHI хранится (или обслуживается) в облаке, потребители раскрывают ее поставщику облака, который, таким образом, становится бизнес-партнером. Поэтому поставщикам облачных сервисов необходимо соблюдать положения HIPAA и HITECH.

Хотя OCR не использует термин " поставщики облачных сервисов ", в комментариях к правилам для определения бизнес-партнеров и субподрядчиков и разъяснения значения термина "обслуживают" используется словосочетание "компании хранения данных". В комментариях указывается, что даже если бизнес-партнер не видит PHI или видит эту информацию случайно или изредка, это не освобождает его от необходимости следовать правилам.

Изменение определения бизнес-партнера и предоставленные комментарии не оставляют сомнений в том, что поставщики облачных сервисов и другие организации, которым доверена PHI (медиинскими организациями), являются бизнес-партнерами. Таким образом, являясь бизнес-партнерами, поставщики облачных сервисов несут безусловные обязательства и повышенную ответственность за PHI.

Соглашения о бизнес-партнерстве

При выполнении операций лечения, оплаты и медобеспечения медицинским организациям разрешено обмениваться информацией EPHI без согласия пациентов. Однако при обмене должен открываться только необходимый минимум EPHI. Таким образом, медицинские организации могут обмениваться EPHI друг с другом и с бизнес-партнерами. Но, открывая эту информацию бизнес-партнеру, медицинские организации обязаны получить убедительные гарантии того, что бизнес-партнер обеспечит надлежащую защиту предоставленной информации. Это требование реализуется с помощью соглашения о бизнес-партнерстве (BAA).

По существу, BAA являются соглашениями об уровне обслуживания (SLA), содержащими конкретные положениями о соблюдении требований HIPAA и HITECH. Медицинские организации обязаны заключать BAA с бизнес-партнерами, которым они предоставляют EPHI. В свою очередь бизнес-партнеры должны заключать BAA со своими субподрядчиками, которым они передают данную информацию. Также бизнес-партнеры должны заключать BAA с их субподрядчиками. В то же время медицинские организации не обязаны заключать отдельные соглашения с субподрядчиками для обеспечения конфиденциальности и безопасности PHI. Четкое определение в BAA ролей и ответственности медицинской организации, бизнес-партнера и субподрядчика позволяет уменьшить ответственность каждого участника соглашения и упростить процессы извещения об утечках.

Соглашения между медицинскими организациями и бизнес-партнерами должны содержать убедительные гарантии того, что бизнес-партнер будет соблюдать Security Rule, сообщая организации об утечках незащищенной PHI, а также обеспечит соблюдение своими субподрядчиками ограничений и условий, касающихся PHI, которые применяются к бизнес-партнерам. Если медицинская организация знает о деятельности или практике бизнес-партнера, которые нарушают BAA, она должна принять надлежащие меры для устранения утечки или прекратить нарушение, а если эти шаги не увенчаются успехом – расторгнуть BAA. Кроме того, в BAA должно быть четко указано, что бизнес-партнер имеет контрактное обязательство соблюдать стандарт Privacy Rule, который применяется к медицинской организации, при выполнении работ для этой организации. Эти требования так же относятся к бизнес-партнерам, заключающим контракты с субподрядчиками.

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

BAA и облако

Четкие BAA особенно важны, если EPHI хранится в облаке. Для поставщиков облачных сервисов BAA должны содержать условия доступа и использования сервиса, период предоставления сервиса, условия прекращения предоставления и использование данных в случае прекращения. Кроме того, соглашение должно включать в себя политику конфиденциальности, описывающую способы обработки информации, а также то, как информация потребителя собирается, используется и управляется поставщиком облака. Хотя ответственность за безопасность и защиту EPHI может передаваться или разделяться, в BAA следует четко указать, что право собственности на данные не переходит к поставщику облака.

Поскольку поставщикам облачных сервисов делегируются только определенные функции (зависящие от сервисов, используемых потребителями), поставщики должны гарантировать, что их соглашения с медицинскими организациями, другими бизнес-партнерами и субподрядчиками содержат детальное описание ролей и ответственности, касающихся PHI. Должно быть указано, кто несет ответственность за создание, реализацию, управление и изменение прав доступа (поставщика и потребителя облачных сервисов), за реагирование на инциденты, шифрование, управление ключами и мониторинг данных, а также за другие вопросы, которые мы обсудим позднее.

Кроме того, поставщик должен четко описать сервисы, которые он предоставляет, за что не несет ответственности и какие риски связаны с каждым предоставляемым им сервисом. Например, поставщик облачных сервисов может предложить хранение данные в различных географических точках. Хранение данных не в том месте, где работает потребитель, или в нескольких местах (для дублирования или резервного копирования данных), гарантирует, что критически важные бизнес-операции не будут прерваны в случае аварийной ситуации. Однако если данные хранятся в других странах, это может привести к проблемам, связанным с международным законодательством, противоречащем законам HIPAA и HITECH. В BAA указывается, где будет храниться PHI-информация потребителя (в США или где-нибудь еще) и кто будет иметь доступ к данным и контроль над ними независимо от их местоположения.

Безусловное обязательство

OCR подчеркивает, что за конфиденциальность и безопасность PHI должны отвечать все, кому она доверена. Формулируя эти правила, OCR поясняет, что хочет "избежать ситуации, когда конфиденциальность и безопасность PHI не обеспечивается только потому, что работа выполняется субподрядчиком, а не бизнес-партнером, напрямую связанным с медицинской организацией". Таким образом, нижележащие организации, работающие по поручению или от имени бизнес-партнеров (например, субподрядчики), а также бизнес-партнеры, работающие от имени медицинских организаций, несут прямую ответственность и подлежат гражданско-правовым денежным санкциям (CMP) за несоблюдение HIPAA.

В частности, бизнес-партнеры непосредственно отвечают за:

  • Недопустимое использование и разглашение ("утечки").
  • Неуведомление об утечке медицинской организации или бизнес-партнера.
  • Непредоставление доступа к электронной PHI медицинской организации или лицу, которых она касается.
  • Нераскрытие PHI министерству при необходимости проведения расследования или проверки бизнес-партнера.
  • Непредоставление отчета о разглашениях.
  • Несоблюдение Security Rule (часть 164, подчасть С).

Поскольку теперь поставщики облачных сервисов несут прямую ответственность, они должны тщательно контролировать данные. Чтобы избежать нарушений, им необходимо постоянно контролировать доступ клиентов к данным, а также обеспечивать надлежащие процедуры аутентификации, о чем пойдет речь ниже. Это снизит риск появления уязвимостей, увеличит шансы обнаружить и исправить нарушения до нанесения ими ущерба, а также облегчит взаимодействие с другими бизнес-партнерами, медицинскими организациями и министерством в случае утечки PHI. При соблюдении надлежащей бдительности и упреждающем подходе поставщики облачных сервисов имеют право защититься от ответственности за возможные нарушения, приняв меры по исправлению положения в течение 30 дней.

Гражданские денежные санкции (CMP)

Эта новая ответственность может быть весьма дорогостоящей для бизнес-партнеров – сумма санкций может составить до 1.5 миллионов долларов в год за нарушение. Однако OCR разъясняете, что это потолок для одного вида нарушений. Также отмечается, что если бизнес-партнер совершает несколько видов нарушений (например, недопустимое использование и разглашение или нарушение защиты), это может привести к гораздо более высоким штрафам. Размер штрафа зависит от умысла (намерения) бизнес-партнера и растет по мере роста тяжести нарушения – от отсутствия умысла (незнание) до наличия умысла (намеренное пренебрежение). В таблице 1 приведены штрафы за нарушения.

Таблица 1. Гражданские денежные санкции за нарушения HIPAA
НарушениеСумма штрафа за нарушениеМаксимальная сумма за все нарушения одного вида в календарном году
(A) Незнание100 $ – 50000 $1500000 $
(B) Достаточное основание1000 $ – 50000 $1500000 $
(C)(i) Умышленное пренебрежение – исправлено10000 $ – 50000 $1500000 $
(C)(ii) Умышленное пренебрежение – не исправлено50000 $1500000 $

При наложении штрафов министерство принимает во внимание много факторов и может изменить сумму штрафа, если она неадекватна нарушению. Министерство рассматривает следующие факторы:

  • характер и масштаб каждого нарушения;
  • характер и масштаб ущерба, причиненного нарушением;
  • количество пострадавших лиц;
  • продолжительность нарушения(ий);
  • характер нанесенного репутационного ущерба (профессиональный, общественный или личный);
  • финансовое положение медицинской организации;
  • показатели невыполнения или выполнения требований.

Облачные сервисы специфичны для каждого потребителя, особенно закрытые облака, настроенные на конкретного клиента. Поэтому предоставляемые облачные сервисы могут быть важным фактором определения сумм штрафов. Например, некоторые потребители могут использовать программное обеспечение как сервис (SaaS), тем самым передавая поставщику облачных сервисов контроль над большей частью своих данных, в том числе над PHI. Потребители также могут использовать открытые облака. В обоих случаях эффективность управления данными позволяет достичь экономии средств. Однако такие сервисы могут стать источником утечек (из-за атак злоумышленника или несанкционированного доступа инсайдера), наносящих ущерб многим лицам в течение короткого периода времени, в то время как потребитель, использующий инфраструктуру как сервис (IaaS) или закрытое облако, может лучше контролировать утечки (см. раздел Контроль над данными).

Тем не менее, какой бы ни была модель облачного сервиса, изменение в Omnibus Rules термина "история нарушений" на "предыдущие показатели невыполнения" (в дополнение к защите от санкции за нарушения, описанной выше) позволяет министерству учитывать добросовестные усилия поставщика облачных сервисов, его бизнес-партнеров и медицинских организаций по устранению или смягчению утечек. Но поскольку поставщики облачных сервисов вряд ли имеют "историю нарушений", упреждающий подход к соблюдению законодательных требований может быть эффективным способом снижения штрафов.

Утечки

HHS определяет утечку EPHI как "недопустимое использование или разглашение... ставящее под угрозу безопасность или конфиденциальность охраняемой информации о здоровье и представляющее значительный риск финансового, репутационного или иного ущерба для индивидуума".

Начиная с 2009 года в результате крупных утечек EPHI, затрагивающих данные медицинских карт 500 и более человек, были скомпрометированы данные почти 21 миллиона человек (см. раздел Ресурсы). Доля бизнес-партнеров в крупных утечках составила 21%. Кроме того, в OCR были направлены отчеты о десятках тысяч утечек, затрагивающих менее 500 медицинских карт.

Наиболее распространенной причиной крупномасштабных утечек является кража (55%), затем идут несанкционированный доступ или разглашение EPHI (20%), потеря информации (11%), взлом (6%), неправильное использование (5%) и неизвестные/другие причины (3%). Рисунок 1 иллюстрирует эту статистику.

Рисунок 1. Утечки данных о здоровье
Рисунок 1. Утечки данных о здоровье
Рисунок 1. Утечки данных о здоровье

Скорее всего, эти цифры не совсем точны. Сегодня могут быть украдены не только бумажные карты, но и ноутбуки. Также потеря информации может быть связана с потерей флэш-накопителя. Кроме того, эти цифры отражают статистику утечек в прошлом; тот факт, что сегодня все больше информации хранится в электронном виде (в том числе в облаке), неизбежно изменит эту статистику. Миграция в облако порождает новые методы атак на EPHI. Теперь эти атаки угрожают EPHI, хранящейся вне места использования, где те, кому она была первоначально доверена, имеют меньше контроля.

Независимо от причин утечки нарушение HIPAA подлежит уголовным и гражданско-правовым санкциям как на уровне штата, так и на федеральном уровне (законом HITECH санкции были усилены). Федеральные гражданско-правовые санкции могут составлять до 1.5 миллиона долларов в год (см. таблицу 1), а уголовные – до 10 лет лишения свободы и до 250000 долларов в виде штрафов, и это без учета штрафов штата.

Извещение об утечке

В настоящее время бизнес-партнеры несут прямую ответственность за утечки PHI, находящейся под их контролем, и должны сообщать о них медицинским организациям (это же должны делать и субподрядчики, имеющие соглашение с бизнес-партнерами). Таким образом, бизнес-партнеры, которые имеют доступ к PHI, обслуживают, хранят, изменяют, записывают, уничтожают или иным образом размещают, используют или разглашают PHI, должны уведомлять медицинскую организацию об утечках этой информации. Отчеты должны направляться незамедлительно, но не позднее 60 дней с момента выявления утечки. Отчет должен содержать идентификационные данные каждого человека, конфиденциальность PHI которого была нарушена. Бизнес-партнеры могут сообщить об утечке сразу, а затем направлять дополнительную информацию по мере ее поступления. Для некоторых бизнес-партнеров (например, поставщиков облачных сервисов) предоставление идентификационных данных каждого человека, чья PHI была разглашена, может оказаться трудной задачей, однако правила рекомендуют, чтобы бизнес-партнеры предоставляли эту информацию "по мере возможности". Стандарт учитывает, что бизнес-партнеры могут не иметь идентификационных данных лиц, конфиденциальность PHI которых была нарушена.

Поставщики облачных сервисов могут быть держателями PHI от нескольких медицинских организаций. В этом случае они должны уведомлять об утечках только те организации, которых это касается. В случае, если из-за структуры облака (например, общие многопользовательские среды) поставщик не может определить, к какой организации относится утечка, он должен уведомить все организации.

После получения извещения об утечке медицинская организация несет полную ответственность за уведомление пострадавших лиц, министерства, средств массовой информации и других организаций. Тем не менее, OCR разрешает сторонам BAA самим определять ответственных за уведомление. OCR предоставляет медицинским организациям и бизнес-партнерам возможность самим определять, кто возьмет на себя ответственность за извещение, а также устанавливать требования относительно того, как, когда и кому должно быть направлено извещение.

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

Соблюдение HIPAA: специфичные проблемы облака

Перенос данных в облако порождает ряд проблем, усложняющих соблюдение HIPAA медицинскими организациями, бизнес-партнерами и самими поставщиками облачных сервисов. Это проблемы контроля, доступа, доступности, общих многопользовательских сред, готовности к инцидентам и реагирования на них, а также защиты данных, каждая из которых рассматривается в оставшейся части статьи. Хотя хранение EPHI в облаке имеет много преимуществ, потребители и поставщики облачных сервисов должны знать, как каждая из этих проблем влияет на соблюдение требований HIPAA и HITECH.

Контроль над данными

Поручая поставщикам облачных сервисов хранение своих данных, потребители отказываются от прямого контроля над этими данными, начиная с уровня приложений. Они жертвуют контролем над данными, поскольку проблемы моделей развертывания в облаке усугубляются географическим расположением данных, в результате чего возникает вопрос, кто имеет доступ к данным. Чтобы понять, как будут соблюдаться требования, необходимо знать, кто имеет контроль над данными и несет за них ответственность. Из-за изменения в контроле при переносе EPHI в облако потребитель и поставщик должны четко определить в BAA (до начала предоставления услуг), кто берет на себя ответственность за конфиденциальность и безопасность данных.

Приложение и инфраструктура

Модели уровня сервиса облачных вычислений (программное обеспечение как сервис (SaaS), платформа как сервис (PaaS) и инфраструктура как сервис (IaaS)) предоставляют потребителям различные уровни контроля, зачастую предлагающие соответствующий компромисс в безопасности. Потребители и поставщики должны найти баланс для своих организаций и определить риск, который они готовы взять на себя, теряя контроль над данными. Ни одна из этих моделей не предоставляет потребителям контроль над базовой облачной инфраструктурой, но потребители имеют больший контроль при использовании IaaS и меньший контроль при использовании PaaS и SaaS. Остается неясным вопрос: если соглашение заключается на уровне приложения или инфраструктуры, передается ли ответственность за данные поставщику облака частично или в полном объеме (т.к. первоначальный владелец больше не имеет полного контроля над данными)? С точки зрения выполнения требований HIPAA и HITECH тот, кто имеет контроль над EPHI, берет на себя повышенную ответственность за безопасность доступа, мониторинг утечек, аудит, управление рисками и т.д.

Модели развертывания

Модели развертывания облака сами влияют на контроль данных независимо от уровня приложения или инфраструктуры. В модели открытого облака инфраструктура общедоступна, а значит при развертывании данных контроль теряется. На другом конце спектра находится инфраструктура закрытого облака, доступная только для одного потребителя. Общественное облако доступно для конкретного сообщества, а гибридное облако совмещает модели открытого и закрытого облака. Для обеспечения наивысшего уровня контроля, а, значит, наибольшей конфиденциальности и безопасности EPHI, необходимо использовать модель закрытого облака. Однако для хранения EPHI могут использоваться и открытые облака; например, Центры по контролю и профилактике заболеваний использовали такую модель для данных синдромного надзора (см. раздел Ресурсы). Тем не менее открытое облако делает EPHI более уязвимой, поэтому потребители, которые предпочитают эту модель, должны хорошо подумать.

Многие поставщики понимают уникальную природу EPHI и меняют свои модели развертывания, предлагая облачные сервисы, специально настроенные на хранение EPHI. Например, некоторые поставщики специально отделяют часть своих облачных сервисов для размещения данных, связанных с EPHI. Однако многие поставщики не делают этого, поэтому такие сервисы могут дорого обойтись потребителям. Таким образом (как и в случае с уровнями приложения и инфраструктуры), потребители должны сами выбирать степень риска, который они готовы взять на себя при размещении данных в открытых, закрытых или гибридных облаках. Независимо от того, где потребители размещают свои данные, поставщики облачных сервисов должны обеспечить конфиденциальность и безопасность EPHI в соответствии с требованиями HIPAA и HITECH с учетом уровня контроля над этими данными, которым они обладают.

Географическое месторасположение данных

Облачные сервисы позволяют хранить данные в нескольких местах, что полезно в чрезвычайных ситуациях (например, отключение электроэнергии, пожар, вандализм, системный сбой или стихийное бедствие). Хранение данных не в том месте, где работает потребитель, или в нескольких местах (для дублирования или резервного копирования данных), гарантирует, что критически важные бизнес-операции не будут прерваны.

Однако потребители, которые не знают, где находятся их данные, теряют контроль над EPHI на другом уровне. Им необходимо знать, где находятся данные, чтобы понимать, какие законы, правила и нормы должны быть соблюдены. В некоторых случаях географическое месторасположение EPHI может привести к проблемам, связанным с международным законодательством, противоречащем законам HIPAA и HITECH.

Доступ к данным

Учитывая, что потребитель теряет контроль над данными на нескольких уровнях, возникает вопрос, кто имеет к ним доступ и как управлять доступом. Существует простое правило: доступ к EPHI должен ограничиваться теми, кому эти данные необходимы. Выполнение этого правила может представлять сложность, если поставщик облака хранит данные в нескольких местах (где имеются свои сотрудники или заключены контракты с третьими сторонами). Рост числа вовлеченных субъектов приводит к тому, что все больше людей имеет возможность получить доступ к EPHI в облаке, увеличивая риски нарушения безопасности данных.

Поставщики и потребители облачных сервисов должны совместными усилиями обеспечить безопасность путем управления предоставлением и изменением прав доступа. Все начинается с определения права пользователя или компьютерной системы на осуществление определенной деятельности (например, чтение файла или запуск программы).

Предоставление прав доступа для персонала

Ответственность за определение тех, кто должен иметь доступ к данным, хранящимся в облаке, лежит на потребителе, а поставщик облака обеспечивает выполнение решений потребителя. Вообще говоря, все сотрудники, которые могут иметь доступ к EPHI, должны пройти процедуру получения допуска. Потребители, поставщики облачных сервисов и те, с кем работают поставщики, должны создать должностные инструкции с четким описанием обязанностей и ответственности, возложенных на каждого сотрудника, а также осуществлять надзор за их соблюдением.

Все сотрудники (как поставщика, так и потребителя облачных сервисов), имеющие доступ к EPHI, должны получить уникальные имена пользователей и пройти обучение по сохранению конфиденциальности своей регистрационной информации (помимо обязательного обучения стандартам Privacy Rule и Security Rule). Каждому пользователю должен быть предоставлен доступ в соответствии с определенной для него ролью, а в случае необходимости права доступа должны быть немедленно изменены или аннулированы.

Аутентификация

Согласно HIPAA, должны быть реализованы процедуры, гарантирующие доступ к EPHI только зарегистрированным лицам. Это может быть система авторизации с использованием уникального имени пользователя и пароля или других данных. Поскольку администрирование учетных данных обеих систем (потребителя и поставщика) может быть громоздким, некоторые поставщики облачных сервисов предлагают интеграцию с системами аутентификации потребителя. Это реализуется с помощью механизмов протокола LDAP или технологий единого входа (SSO). Однако эти методы могут сами стать источником угроз безопасности.

Поставщики облачных сервисов могут также использовать язык разметки подтверждения безопасности (SAML) для аутентификации в режиме реального времени, подтверждения транзакций, а также для предоставления и аннулирования доступа. Согласно документу NIST "Рекомендации по безопасности и конфиденциальности открытых облачных вычислений" (см. раздел Ресурсы), если языка SAML не достаточно, поставщики облачных сервисов могут также использовать расширяемый язык разметки контроля доступа (XACML), "чтобы адаптировать права потребителей облака и сохранить контроль над доступом к ресурсам".

Аудит доступа

С точки зрения доступа наиболее важно, чтобы поставщики и потребители облачных сервисов согласовывали процедуры аудита доступа. Стандарт Security Rule требует регулярного анализа отчетов об активности в информационной системе (таких как журналы аудита, отчеты о доступе и отчеты о нарушении безопасности) для выявления любого неприемлемого разглашения EPHI. Кроме того, для регистрации и изучения активности в информационных системах, содержащих или использующих EPHI, необходимо применять аппаратные, программные и/или процедурные механизмы. Закон HITECH требует дополнительного мониторинга утечек EPHI. Аудит является предметом особого внимания HIPAA и HITECH, потому что от него зависят реагирование на инциденты, порядок извещения об утечках и, в конечном счете, возможность прекратить утечки и смягчить их последствия.

Целостность

Целостность EPHI зависит от того, кто имеет доступ к данным. Поставщики и потребители обязаны не только определить, кто имеет доступ к EPHI, хранящейся в облаке, но также поддерживать целостность данных и защищать их от подделки. Фактически целостность является одной из основных задач Security Rule. Security Rule определяет целостность как "свойство, заключающееся в том, что данные или информация не были изменены или уничтожены несанкционированным способом". Если EPHI хранится в облаке, число путей доступа к ней постоянно растет. Поэтому обеспечивать целостность данных становится все труднее.

Общая многопользовательская среда

Открытые облачные сервисы экономически выгодны благодаря тому, что такая инфраструктура часто включает в себя общие многопользовательские среды, в результате чего потребители используют компоненты и ресурсы совместно с другими потребителями, которые им неизвестны. Однако с этой возможностью связанны большие риски, такие как доступ одного потребителя к данным другого и смешение данных. Кроме того, в общей многопользовательской среде один потребитель может уменьшить доступность и производительность ресурсов для другого потребителя, а выполнение поставщиком обновлений или исправлений может помешать бизнес-деятельности потребителей. Кроме того, существует риск, что поставщики облачных сервисов не смогут отделить в общей инфраструктуре деятельность одного арендатора от другого. Это важно для мониторинга и аудита доступа, а также для удаления данных, которое имеет решающее значение с точки зрения выполнения требований HIPAA и HITECH. Для решения этих проблем поставщикам облачных сервисов необходимо четко определить подходы к изоляции; это могут быть технологии виртуализации, изоляция на уровне приложений или изоляция на уровне базы данных.

Доступность данных

Одной из норм Security Rule является доступность EPHI, особенно в случае аварийной ситуации или других инцидентов. Одним из преимуществ переноса EPHI в облако является возможность повышения доступности данных различными способами. Облачные сервисы, которые хранят избыточные данные в нескольких местах, лучше справляются с аварийными ситуациями. Кроме того, наращивание ресурсов по требованию обеспечивает устойчивость при росте числа запросов к сервису и позволяет минимизировать плановые перерывы в работе сервиса, связанные с обслуживанием и устранением неисправностей. Кроме того, облачные сервисы могут смягчить атаки типа "отказ в обслуживании" (DoS), когда на целевую систему направляются многочисленные фиктивные запросы, препятствующие своевременному реагированию на реальные запросы.

Наконец, облачные сервисы можно использовать через Интернет или виртуальную закрытую сеть (VPN) с помощью интерфейсных сервисов – Web-браузера или приложения, предоставленного поставщиком облака. Такое взаимодействие может подвергать EPHI рискам перехвата данных во время их передачи, фальсификации или повреждения данных и аутентификации на клиенте и сервере. Проект Open Web Application Security (OWASP) предоставляет список 10 наиболее часто встречающихся уязвимостей архитектуры и дизайна Web-приложений, которые необходимо учитывать на протяжении всего жизненного цикла разработки программного обеспечения (см. раздел Ресурсы).

Готовность к инцидентам и реагирование на них

Реагирование на инциденты является ключевой проблемой соблюдения HIPAA и HITECH. Учитывая, что независимо от количества принятых мер не все инциденты (будь то авария, несанкционированный доступ, кража, взлом, потеря, ошибка сотрудника и т.д.) можно предотвратить, стандарты Privacy Rule and Security Rule делают особый акцент на:

  • важности реагирования на инциденты и уменьшения ущерба;
  • минимизации перерывов в выполнении критически важных бизнес-операций;
  • обеспечении безопасности и конфиденциальности EPHI.

Готовность к инцидентам

Еще до возникновения инцидента потребители и поставщики должны разработать определенные политики и процедуры, например, план работ в аварийной ситуации. Они также должны выполнять профилактический мониторинг угроз и уязвимостей. Первым требованием стандарта Security Rule является выполнение оценки риска. Потребители должны регулярно выполнять собственные оценки риска как для данных, хранящихся в компании, так и для данных, хранящихся в другом месте (например, в облаке). Кроме того, поставщики облачных сервисов должны выполнять оценки риска своей инфраструктуры. Любые обнаруженные уязвимости должны быть задокументированы. Поставщики облачных сервисов должны сообщать о таких уязвимостях потребителям, чтобы они могли определить приемлемость рисков или устранить уязвимости.

Наряду с определением месторасположения EPHI и оценкой риска потребители должны выполнять резервное копирование своих данных. Необходимо создать и поддерживать "восстановимую точную копию" EPHI. Для выполнения этого требования облачные сервисы предоставляют возможность внешнего резервного копирования данных. Вопрос в том, где должна храниться резервная копия, как получить доступ к данным резервной копии, как давно она была создана и как долго она сохраняется.

Кроме того, как отмечалось ранее, большое значение имеет управление доступом. Потребители и поставщики облачных сервисов должны контролировать доступ к EPHI и гарантировать, что его получат только авторизованные пользователи, прошедшие аутентификацию. Тех, кто больше не должен иметь доступа, необходимо удалить из списка пользователей.

Наконец, поставщики и потребители облачных сервисов должны постоянно выполнять тестирование на наличие уязвимостей и соответствующим образом корректировать свои политики и процедуры. Поставщики облачных сервисов должны немедленно сообщать потребителям о проблемах, которые они обнаружили в результате тестирования, а также о любых выполненных изменениях.

Реагирование на инциденты

Поставщик облака играет важную роль в реагировании на инциденты и несет ответственность за проверку и анализ инцидентов, локализацию последствий, сбор данных, хранение, устранение проблем и восстановление нормального режима работы. Как уже говорилось, изучение журналов аудита является первым шагом в анализе атак и реагировании на инциденты. После изучения этих журналов и результатов расследования усилия поставщика должны быть направлены на локализацию последствий инцидента для обеспечения конфиденциальности, целостности и доступности EPHI. Используя дублирующие или резервные копии, поставщик облака может исправить или восстановить данные до предыдущего состояния.

Потребители должны определить, чего они ожидают от поставщиков облачных сервисов в случае инцидента – в частности, как будет выполняться проверка инцидента и как будет собираться информация для его анализа. Кроме того, потребители и поставщики должны оговорить время восстановления и точки восстановления, а также обеспечить координацию действий при восстановлении.

Защита данных

Передаваемые данные, данные в состоянии покоя и резервные копии можно защитить несколькими способами. Большинство мер защиты должны предпринимать поставщики облачных сервисов, поскольку они контролируют EPHI. Эти меры включают в себя мониторинг утечек, шифрование, управление ключами и удаление данных.

Мониторинг утечек данных

Передавая контроль над данными поставщику облака, потребители вынуждены опираться на процессы, которые поставщик использует для мониторинга утечек данных в своих системах. Это может быть использование сетевых экранов, обнаружение вторжений в сеть, мониторинг журналов сервера и доступа конечного пользователя к файлам. Какие бы методы ни использовались, поставщики облачных сервисов должны регулярно выполнять проверки, чтобы гарантировать их работоспособность. При обнаружении утечки или уязвимости поставщик облака должен сообщить об этом потребителю.

Шифрование

Организации могут шифровать данные, чтобы сделать их непригодными для использования, нечитаемыми или неподдающимися расшифровке неавторизованными лицами. Согласно Security Rule, шифрование EPHI – это "алгоритмический процесс преобразования данных к такому виду, когда определение их смысла без использования конфиденциального процесса или ключа маловероятно" либо без нарушения конфиденциального процесса или ключа, обеспечивающих дешифрование. Согласно OCR, потребители и поставщики облачных сервисов могут использовать процессы шифрования, проверенные институтом NIST. Шифрование данных в состоянии покоя должно соответствовать NIST Special Publication 800-11, а передаваемых данных – NIST Special Publication 800-52 и 800-77 (см. раздел Ресурсы).

Управление ключами

Схемы управления ключами шифрования являются еще одним способом защиты данных. Потребители могут использовать этот инструмент самостоятельно или через поставщика облачных сервисов. Хотя некоторые из них уже используют управление ключами, отраслевые стандарты еще находятся в стадии разработки, которую осуществляют такие организации как Институт инженеров электротехники и электроники (IEEE) и Организация по продвижению стандартов структурированной информации (OASIS) – разработчик протокола совместимости управления ключами (KMIP). Те, кто уже использует схемы управления ключами, должны решить вопросы обеспечения безопасности хранилищ ключей, ограничения доступа к хранилищам, а также их резервного копирования и восстановления.

Удаление данных

Согласно Security Rule медицинские организации и бизнес-партнеры должны "осуществлять политики и процедуры, касающиеся окончательной ликвидации электронной информации о здоровье и/или аппаратных средств или электронных носителей, на которых она хранится". Поэтому поставщики облачных сервисов должны обеспечивать по просьбе потребителей корректное удаление EPHI и невозможность ее повторного создания, в том числе из резервных копий. Такая очистка данных включает в себя стирание EPHI с носителя путем перезаписи, размагничивания и т.д. OCR считает носители, на которых хранится (или записывается) EPHI, очищенными, если выполнены Рекомендации института NIST по уничтожению данных. Физическое размещение общих или смешанных данных в открытом облаке затрудняет их уничтожение и требует дополнительных усилий.

Рекомендации

Объединенные правила Omnibus Rules, модифицирующие правила HIPAA Privacy and Security Rules, Breach Notification Rule и Enforcement as required by the HITECH Act, существенно меняют роль и ответственность бизнес-партнеров и субподрядчиков. В определение бизнес-партнера вводится понятие "субподрядчик", при этом подчеркивается, что регулированию также подлежит бизнес-партнер, работающий с PHI от имени медицинской организации или другого бизнес-партнера. Таким образом, бизнес-партнеры (к которым относятся поставщики облачных сервисов) должны предпринять новые шаги для обеспечения соблюдения требований HIPAA и HITECH, иначе они столкнутся с очень высокими штрафами.

Поскольку поставщики облачных сервисов являются бизнес-партнерами и несут прямую ответственность за утечки, они должны незамедлительно выполнять оценку рисков для PHI, которую они создают, получают, хранят или передают, с точки зрения наличия уязвимостей и скорейшего их устранения. Чтобы обеспечить соблюдение Privacy Rule и Security Rule, поставщики облачных сервисов должны выполнять внутренний аудит своих политик и процедур. Необходимо организовать обучение вышеуказанным правилам сотрудников предприятия и назначить лиц, ответственных за конфиденциальность и безопасность, которым сотрудники могли бы незамедлительно сообщать об известных им инцидентах. Необходимо пересмотреть соглашения BAA (как описано выше), чтобы определить роли и ответственность всех сторон, предоставляемые сервисы и ответственных за извещение об утечках PHI.

Для наилучшего соблюдения нормативных требований поставщики облачных сервисов должны использовать протокол OCR Audit Protocol (см. раздел Ресурсы), который объединяет требования Privacy Rule, требования Security Rule к административным, физическим и техническим мероприятиям, а также требования Breach Notification Rule. Этот комплексный инструмент, специально разработанный для медицинских организаций и бизнес-партнеров, содержит требования, оцениваемые в процессе аудита, обязательного для выполнения OCR согласно закону HITECH.

Правила Omnibus Rules развивают заложенные в HIPAA концепции защиты конфиденциальной информации о здоровье пациентов и обеспечения доступности и достоверности этой информации. Беря на себя ответственность за PHI в качестве бизнес-партнера или субподрядчика, поставщики облачных сервисов, обязуются следовать тем же стандартам, что и медицинские организации, особенно если они дорожат доверием пациентов. Понимая и четко определяя свою роль бизнес-партнера или субподрядчика, поставщик облачных сервисов может не только избежать суровых санкций, но и сохранить репутацию надежного партнера в сфере здравоохранения.

В конечном счете, ответственность важна не только для соблюдения HIPAA и HITECH, но и для обеспечения доверия. Врач доверяет бизнес-партнеру критичную информацию пациентов, открывших свои самые конфиденциальные данные, которые в виде EPHI могут быть размещены в облаке. В случае компрометации EPHI пациентов они могут потерять доверие к своим врачам, что может поставить под угрозу их лечение. Таким образом, значение HIPAA и HITECH выходит за рамки законодательства. EPHI – это не просто данные. За ней стоят люди, их здоровье и жизни.


Ресурсы для скачивания


Похожие темы

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=993528
ArticleTitle=Конфиденциальность и безопасность данных пациентов в облаке
publish-date=04162013