Домен безопасности: безопасность и конфиденциальность обработки данных

Этот домен безопасности предназначен для обеспечения надлежащей защиты всех данных, используемых из Microsoft 365, как при передаче, так и при хранении. Эта область также гарантирует, что проблемы конфиденциальности потребителей (субъектов данных) будут удовлетворены ISV в соответствии с GDPR (Общий регламент по защите данных) и HIPAA (Закон о переносимости и подотчетности медицинского страхования 1996 года).

Передаваемые данные

Требования к подключению приложений и надстроек, разработанных в Microsoft 365, требуют обмена данными через общедоступные сети, в частности Через Интернет. Таким образом, передаваемые данные должны быть надлежащим образом защищены. В этом разделе рассматривается защита передачи данных через Интернет.

Элемент управления No 1

ЖЕСТКИЙ СБОЙ

Предоставьте доказательства того, что:

• Вся конфигурация TLS имеет значение TLS1.2 или более поздней версии, как указано в разделе Требования к конфигурации профиля TLS.

• Хранится и поддерживается инвентаризация доверенных ключей и сертификатов.

Требования к конфигурации профиля

Намерение: TLS

Эта подзапункт направлена на обеспечение безопасной передачи данных Microsoft 365, используемых вашей организацией. Конфигурация профиля TLS используется для определения конкретных требований TLS, которые помогают обеспечить безопасность трафика от атак типа "злоумышленник в середине".

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

Самый простой способ доказать это — запустить средство тестирования СЕРВЕРА SSL Qualys для всех веб-прослушивателей, включая все, которые выполняются на нестандартных портах.

Не забудьте установить флажок "Не показывать результаты на досках", который запрещает добавление URL-адреса на веб-сайт.

Требования к конфигурации профиля TLS можно продемонстрировать, предоставив свидетельство отдельных проверок. Чтобы предоставить свидетельство о конкретных параметрах, таких как отключение сжатия TLS, можно использовать параметры конфигурации, скрипты и программные средства.

Пример доказательства: TLS

На следующем снимку экрана показаны результаты проверки SSL Qualys для веб-приложенияfrontdoor-byendbagh6a0fcav.z01.azurefd.net.

В разделе Протоколы показано, что протокол TLS1.2 является единственным поддерживаемым или включенным протоколом.

Примечание. Аналитики сертификации проверят полные выходные данные проверки, чтобы убедиться, что выполнены все требования к конфигурации профиля TLS. Ожидается, что проверки будут предоставляться для всех конечных точек, общедоступных (IP-адреса и URL-адреса) в серверной среде, которая находится в область. В зависимости от того, какие доказательства были предоставлены, аналитики могут выполнить собственное сканирование Qualys.

Пример доказательства: TLS

На следующем снимке экрана показаны параметры конфигурации для TLS в службе приложений Azure, а затем перечисление TLS с помощью PowerShell.

Намерение: ключи и сертификаты

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

Рекомендации: ключи и сертификаты

Свидетельство должно демонстрировать, что инвентаризация доверенных ключей и сертификатов существует и поддерживается. Кроме того, можно предоставить применимые свидетельства о средствах, используемых для хранения фактических ключей и сертификатов, таких как Azure хранилище ключей, секреты HashiCorp Vault, Confluence Cloud и т. д.

Пример свидетельства: ключи и сертификаты

На следующем снимке экрана показано, что ключ и список сертификатов хранятся в Confluence Cloud.

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

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

На следующем снимок экрана показан извлечение фактического сертификата и ключей, хранящихся в интернет-хранилище.

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

Пример свидетельства: ключи и сертификаты

Инвентаризация доверенных ключей и сертификатов также может вестись с помощью Microsoft 365 Defender, который предоставляет функцию инвентаризации, как показано на следующем снимке экрана.

На следующем снимку экрана показаны сведения о сертификате.

Обратите внимание: эти примеры не являются полноэкранными снимками экрана. Вам потребуется отправить полноэкранные снимки экрана с любым URL-адресом, вошедшего в систему пользователя, а также меткой времени и даты для проверки доказательств. Если вы являетесь пользователем Linux, это можно сделать с помощью командной строки.

Элемент управления No 2

Предоставьте доказательства того, что:

• Сжатие TLS отключено для всех общедоступных служб, обрабатывающих веб-запросы, чтобы предотвратить утечку данных коэффициента сжатия, сделанную easy (CRIME).

• Протокол TLS HTTP Strict Transport Security (HSTS) включен и настроен на минимальный возраст в 180 дней на всех сайтах.

  Намерение: TLS

• Атака CRIME (Утечка сведений о коэффициенте сжатия, сделанная простой (CVE-2012-4929)) — это уязвимость при сжатии протоколов SSL/TLS. По этой причине отраслевые рекомендации по отключению сжатия SSL.

• Http Strict Transport Security (HSTS) — это механизм безопасности, предназначенный для защиты веб-сайтов от атак типа "злоумышленник в середине", путем принудительного подключения TLS с помощью поля заголовка ответа HTTPS с именем Strict-Transport-Security.

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

Об этом можно узнать с помощью инструмента Qualys SSL Labs. Пример доказательства: TLS

На следующем снимку экрана показано, что сжатие SSL/TLS отключено.

На следующем снимках экрана показано, что протокол HSTS включен.

Примечание. Аналитик по сертификации проверит полные выходные данные, чтобы убедиться, что выполнены все требования к конфигурации профиля TLS (предоставьте снимки экрана с выходными данными полного сканирования). В зависимости от того, какие доказательства были предоставлены, аналитики могут выполнить собственное сканирование Qualys.

Другие средства, которые можно использовать для проверка, что HSTS включен, — это "Шпион заголовков HTTP", и

securityheaders.com, как показано в примерах ниже. Дополнительные доказательства

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

На следующих снимках экрана показана конфигурация Azure Front Door и набор правил, реализованный для перезаписи заголовков.

На следующем снимку экрана показана проверка заголовков безопасности и реализованы все заголовки безопасности, а не только HSTS.

Примечание. Если используется сканер SSL Qualys или заголовки безопасности, ожидается, что полный отчет будет предоставлен для проверки.

Неактивные данные

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

Элемент управления No 3

ЖЕСТКИЙ СБОЙ

Предоставьте доказательства того, что:

• Неактивные данные шифруются в соответствии с требованиями профиля шифрования с использованием алгоритмов шифрования, таких как; Advanced Encryption Standard (AES), Blowfish и XChaCha20.

• Размер ключа шифрования не менее 128 бит.

Требования к профилю шифрования

Намерение:

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

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

Доказательства можно предоставить на снимках экрана, показывающих шифрование, используемое для защиты данных M365 в базах данных и других местах хранения. Свидетельство должно демонстрировать, что конфигурация шифрования соответствует требованиям к конфигурации профиля шифрования сертификации Microsoft 365.

Пример доказательства:

На следующем снимку экрана показано, что В базе данных Contoso включен TDE (прозрачное шифрование данных). На втором снимку экрана показана страница документации Майкрософт Прозрачное шифрование данных для База данных SQL, Управляемый экземпляр SQL и Azure Synapse Analytics, показывающая, что шифрование AES 256 используется для Azure TDE.

Обратите внимание: в предыдущих примерах полные снимки экрана не использовались, однако все снимки экрана, отправленные isV, должны быть полными снимками экрана с URL-адресом, любым вошедшего в систему пользователем, системным временем и датой.

Пример доказательства:

На следующем снимке экрана показано, Azure хранилище, настроенное с шифрованием больших двоичных объектов и файлов. На следующем снимок экрана показана страница документации Майкрософт Azure шифрование хранилища для неактивных данных, на которой показано, что хранилище Azure использует AES-256 для шифрования.

Хранение, резервное копирование и удаление данных

Если поставщики программного обеспечения используют и хранят данные Microsoft 365, существует риск компрометации данных, если субъект угрозы скомпрометировать среду ISV. Чтобы свести к минимуму этот риск, организации должны хранить только данные, необходимые для предоставления услуг, а не данные, которые «могут» пригодиться в будущем. Кроме того, данные должны храниться только до тех пор, пока это необходимо для предоставления служб, для которые были записаны данные. Хранение данных должно определяться и взаимодействовать с пользователями. После того как данные превысят определенный срок хранения, их необходимо безопасно удалить, чтобы данные не были восстановлены или восстановлены.

Элемент управления No 4

Предоставьте доказательства того, что:

Официально устанавливается и документируется утвержденный период хранения данных.

Намерение:

Задокументированная и следуемая политика хранения важна не только для выполнения некоторых юридических обязательств, например законодательства о конфиденциальности данных, такого как, помимо прочего, Общего регламента по защите данных (GDPR ЕС) и Закона о защите данных (UK DPA 2018), но и для ограничения риска организаций. Понимая требования к данным организации и время, необходимое для выполнения бизнесом своих функций, организации могут обеспечить надлежащее удаление данных по истечении срока их использования. Уменьшая объемы хранящихся данных, организации сокращают объем данных, которые будут предоставляться в случае компрометации данных. Это ограничит общее влияние.

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

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

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

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

Пример доказательства:

На следующем снимку экрана показана политика хранения данных Contoso.

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

Элемент управления No 5

Предоставьте доказательства того, что:

Данные хранятся только в течение определенного периода хранения, как описано в элементе управления 4.

Намерение:

Цель этого элемента управления — просто проверить, соблюдаются ли определенные сроки хранения данных. Как уже обсуждалось, организации могут иметь юридическое обязательство по этому вопросу, но также путем хранения данных, которые необходимы и до тех пор, пока это необходимо, помогает снизить риск для организации в случае нарушения безопасности данных. Это гарантирует, что данные не будут храниться в течение слишком длительного времени или преждевременно удаляться. Оба из них могут представлять риски различного характера — юридические, операционные или связанные с безопасностью.

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

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

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

Пример доказательства:

Ниже показан SQL-запрос, показывающий содержимое таблицы базы данных, упорядоченной по возрастанию в поле "DATE_TRANSACTION" для отображения самых старых записей в базе данных. Это показывает, что данные старше двух месяцев, что не превышает определенный срок хранения.

Примечание. Это тестовая база данных, поэтому в ней не так много исторических данных.

Примечание. В предыдущих примерах полные снимки экрана не использовались, однако все снимки экрана, отправленные isV, должны быть полными снимками экрана с URL-адресом, любым вошедшего в систему пользователем, системным временем и датой.

Элемент управления No 6

Предоставьте доказательства того, что:

Существуют процессы для безопасного удаления данных по истечении срока хранения.

Намерение:

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

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

Если процесс удаления выполняется программным способом, укажите снимок экрана скрипта, который используется для этого. Если оно выполняется по расписанию, укажите снимок экрана, показывающий расписание. Например, скрипт для удаления файлов в общей папке может быть настроен как задание CRON. Снимок экрана: задание CRON с расписанием и выполняемым скриптом; и укажите скрипт, показывающий используемую команду.

Пример доказательства:

Это простой скрипт, который можно использовать для удаления всех записей данных, сохраненных на основе даты .WHERE DateAdd — -30 дней, который будет очищать все сохраненные записи старше 30 дней после выбранной даты хранения данных. Обратите внимание, что нам потребуется скрипт. свидетельство выполняемого задания и результатов.

Обратите внимание: в предыдущих примерах полные снимки экрана не использовались, однако все снимки экрана, отправленные isV, должны быть полными снимками экрана с URL-адресом, любым вошедшего в систему пользователем, системным временем и датой.

Пример доказательства:

Следующий снимок экрана взят из политики хранения данных Contoso (из элемента управления 4) — здесь показаны процедуры, используемые для уничтожения данных.

Примечание. На этом снимку экрана показана snapshot документа политики или процесса. Ожидается, что поставщики программного обеспечения будут совместно использовать фактическую документацию по политике или процедуре поддержки, а не просто предоставить снимок экрана.

Пример доказательства:

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

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

Примечание. Для этих снимков экрана должны отображаться полный URL-адрес и имя пользователя, и для отображения снимка экрана с числом записей перед удалением и снимок экрана после удаления записей.

Эти снимки экрана являются чисто примерами различных подходов к этому.

Элемент управления No 7

Предоставьте доказательства того, что:

• Существует автоматизированная система резервного копирования, настроенная для выполнения резервного копирования по расписанию в соответствии с документированной процедурой резервного копирования.

• Сведения о резервном копировании периодически восстанавливаются для подтверждения надежности и целостности данных в рамках описанной процедуры резервного копирования.

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

Намерение:

Цель этого элемента управления — подтвердить наличие в организации автоматизированной системы резервного копирования, которая настроена для выполнения резервных копий в предопределенное время.

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

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

Пример доказательства:

Следующий снимок экрана относится к База данных Azure для MySQL, который является управляемым экземпляром. Это означает, что первая автоматическая архивация завершена.

Следующий снимок экрана делается после того, как истек период, показывающий, что были сделаны дальнейшие полные резервные копии. Резервные копии на гибких серверах основаны на snapshot, где первое резервное копирование snapshot планируется сразу после создания сервера, а последующие snapshot резервные копии создаются один раз в день.

На следующем снимок экрана показан snapshot документации по сети, в которой описана частота резервного копирования и возможность автоматического резервного копирования.

Намерение:

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

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

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

Пример доказательства:

На следующем снимке экрана показано, что расписание резервного копирования и процедура восстановления существует и поддерживается, а также что конфигурация резервного копирования определена для всех применимых систем, включая частоту резервного копирования, выполняемую на платформе Confluence.

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

На следующих четырех следующих снимках экрана показан комплексный процесс восстановления База данных Azure для MySQL из snapshot. С помощью параметра "Быстрое восстановление" можно инициировать процесс восстановления базы данных SQL.

На следующем снимку экрана показана страница конфигурации, на которой можно настроить восстановление.

После выбора целевого расположения, сети и snapshot, из которых будет восстановлена база данных, можно инициировать развертывание. Обратите внимание, что наш экземпляр базы данных теперь называется test.

Через пять минут база данных SQL была успешно восстановлена из резервного snapshot, как показано ниже.

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

Намерение:

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

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

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

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

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

Пример доказательства:

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

Пример доказательства:

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

Управление доступом к данным

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

Элемент управления No 8

Предоставьте доказательства того, что:

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

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

• Пользователи настраиваются с привилегиями, указанными в утверждениях.

Примечание. Выборка пользователей будет выбрана для демонстрации точек B и C.

Намерение:

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

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

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

Пример доказательства:

В следующем документе показан задокументирован список пользователей с доступом к данным и бизнес-обоснование.

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

Намерение:

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

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

Как правило, доказательства, предоставленные для предыдущего элемента управления, могут помочь в поддержке этого элемента управления. Если официального утверждения предоставленной документации нет, то подтверждение может состоять из запроса на изменение, который был вызван и утвержден для доступа в средстве, например, Azure DevOps или Jira.

Пример доказательства:

На этом наборе изображений показаны билеты Jira, созданные и утвержденные для элемента управления (i) для предоставления или запрета доступа к конфиденциальным данным и (или) ключам шифрования. На этом изображении показано, что в Jira создан запрос для получения утверждения Sam Daily для ключей шифрования в серверной среде систем. Это делается в качестве следующего шага, на котором была получена письменная авторизация.

Это показывает, что запрос на предоставление доступа Сэм Daily был одобрен Джоном Смитом человеком из руководства. (Обратите внимание, что утверждение должно исходить от пользователя с достаточными полномочиями, чтобы разрешить запрос на изменение. Это не может быть другой разработчик).

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

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

Чтобы выполнить требования этого элемента управления, необходимо отобразить все эти снимки экрана или аналогичные или эквивалентные доказательства, применимые с объяснением, чтобы продемонстрировать, что вы выполнили требование элемента управления.

Обратите внимание: в предыдущих примерах полные снимки экрана не использовались, однако все снимки экрана, отправленные isV, должны быть полными снимками экрана с URL-адресом, любым вошедшего в систему пользователем, системным временем и датой.

Пример доказательства:

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

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

Обратите внимание: в предыдущих примерах полные снимки экрана не использовались, однако все снимки экрана, отправленные isV, должны быть полными снимками экрана с URL-адресом, любым вошедшего в систему пользователем, системным временем и датой.

Intent

Цель этой вложенной точки — убедиться, что доступ к данным и (или) ключу шифрования настроен в соответствии с документом.

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

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

Пример доказательства:

На этом снимку экрана показаны разрешения, предоставленные пользователю "John Smith", которые будут перекрестными

ссылается на запрос на утверждение для того же пользователя, что и для доказательства предыдущего элемента управления.

Обратите внимание: следующий пример не является полноэкранным снимка экрана. Вам потребуется отправить полноэкранные снимки экрана с любым URL-адресом, вошедшего в систему пользователя, а также меткой времени и даты для проверки доказательств. Если вы являетесь пользователем Linux, это можно сделать с помощью командной строки.

Элемент управления No 9

Предоставьте доказательства того, что:

• Сохраняется список всех третьих лиц, которым предоставляется общий доступ к данным.

• Соглашения об обмене данными ются со всеми третьими лицами, потребляющими данные.

Намерение:

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

Организациям следует вести список всех третьих лиц, с которыми они обмениваются данными, с некоторыми или всеми следующими:

• какие службы предоставляются

• к каким данным предоставлен общий доступ

• почему данные являются общими

• ключевые контактные данные (т. е. основной контакт, контакт с уведомлением о нарушении, DPO и т. д.)

• продление или истечение срока действия контракта

• правовые обязательства и обязательства по соответствию (например, GDPR, HIPAA, PCI DSS, FedRAMP и т. д.)

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

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

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

Пример доказательства:

Обратите внимание: в предыдущих примерах полные снимки экрана не использовались, однако все снимки экрана, отправленные isv, должны быть полными снимками экрана с URL-адресом, любым вошедшего в систему пользователем, системным временем и датой.

Пример доказательства:

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

Обратите внимание: в этих примерах полные снимки экрана не использовались, однако все снимки экрана, отправленные isV, должны быть полными снимками экрана с URL-адресом, любым вошедшего в систему пользователем, системным временем и датой.

Намерение:

Если данные M365 передаются третьим лицам, важно, чтобы данные обрабатывались надлежащим образом и безопасно. Соглашения об обмене данными должны быть приняты, чтобы третьи стороны обрабатывали данные только по мере необходимости и понимали свои обязательства по обеспечению безопасности. Безопасность организации так же сильна, как самое слабое звено. Цель этого элемента управления заключается в том, чтобы третьи стороны не стали слабым звеном организации.

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

Предоставьте соглашения об обмене данными, заключенные с третьими лицами.

Пример доказательства:

На следующем снимку экрана показан упрощенный пример соглашения об обмене данными.

Примечание. Необходимо предоставлять общий доступ к полному соглашению, а не снимок экрана.

Конфиденциальность

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

Элемент управления No 10 — персональные данные

Предоставьте доказательства того, что ваша организация:

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

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

• Разрабатывает и применяет политики, определяющие типы персональных данных, которые можно собирать, и цели их использования. 

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

Намерение:

Цель этого элемента управления заключается в том, чтобы убедиться, что вы придерживаетесь конфиденциальности данных, связанную со сбором данных, гарантируя, что есть оправдание для захвата данных и быть прозрачным с тем, что и зачем собираются данные. Кроме того, важно, чтобы пользователи (субъекты данных) имели возможность отказаться от обработки.  

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

Этот элемент управления может быть подтвержден следующим образом:

A) Предоставьте текущую версию записи об обработке (RoPA) организации (см. статью 30 GDPR) или аналогичный документ с подробными сведениями об элементах данных и целями обработки (см. статью 5.1.b GDPR). 

В большинстве случаев это электронная таблица Excel (которую можно извлечь из таких средств, как OneTrust). 

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

Несоответствующие. Записи не существуют, являются очень старыми или устаревшими или отсутствуют в ключевых полях. 

B) Для целей минимизации данных (см. статью 5.1.c GDPR) предоставьте все формы, используемые для получения данных в Интернете, с помощью планшетов или аналогичных устройств (например, в конференции) или документа. Это могут быть пустые шаблоны. 

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

В) В целях "законности, справедливости и прозрачности" (см. статью 5.1.a GDPR) политика конфиденциальности (предназначенная для сотрудников) должно быть в силе Уведомление о конфиденциальности (предназначено для пользователей или клиентов). Как правило, уведомление о конфиденциальности должно быть общедоступным на веб-сайте организации.  

Несоответствующие. Политики не существуют или отсутствуют в них ключевые элементы. 

Ключевые элементы:

Политика конфиденциальности или уведомление: сбор и использование информации, обработанные элементы данных, цели обработки, законность обработки, передача данных в другие страны, права субъекта данных, хранение и хранение данных.  

Г) Для механизма отказа (см. статью 4.11 GDPR, статью 6 GDPR и статью 7 GDPR), как правило, на веб-странице. Проверьте навигацию, за которую пользователь должен следовать, чтобы добраться до этой страницы (например, ее легко найти?). 

Несоответствующие: нет четкой функциональности отказа или "универсального" отказа без детализации. 

Пример доказательства:

Для A):

Для B):

Для C):

Для D):

Элемент управления No 11 — осведомленность пользователей

Предоставьте доказательства того, что пользователи знают о:

• Кто имеет доступ к их данным.

• У кого есть доступ к пространствам, в которых они работают.

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

Намерение:

Цель этого контроля заключается в том, чтобы продемонстрировать соблюдение принципа защиты данных "Прозрачность" (см. статью 5.1.a GDPR).

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

Чтобы продемонстрировать, что это в идеале, должно быть включено подтверждение пользователем (например, чтобы прочитать Политику конфиденциальности) должно быть в наличии и записано.

На практике только в политике конфиденциальности (для сотрудников), в уведомлении о конфиденциальности (для пользователей и клиентов) содержатся достаточные сведения о следующем:

— кому предоставляется доступ к персональным данным (обработчикам, субпроцессорам, третьим лицам, подрядчикам и т. д.).

Не соответствует требованиям: не существует подтверждений, или политика конфиденциальности или уведомление о конфиденциальности не существуют.

Пример доказательства:

ИЛИ

Элемент управления No 12 — соглашения об обработке данных (DPA)

Предоставьте подтверждение Соглашения об обработке данных, которое должно содержать список всех утвержденных сторон или субпроцессоров.

Намерение:

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

Кроме того, когда совместное использование данных будет включать передачу данных в территории за пределами ЕС (в соответствии с GDPR), подробные сведения о механизме обеспечения законности передачи. (См. статью 5 GDPR и статью 44-50 GDPR)

Для GDPR территории для обработки должны соответствовать одному из следующих условий:

- Быть государством-членом Европейского союза.

- Быть сочтены Европейской комиссией для предоставления "адекватных гарантий". Текущий список можно найти здесь: Адекватность защиты данных для стран, не являющихся странами ЕС.

По состоянию на¹³ июня 2025 г.:

— Будьте частью платформы конфиденциальности данных (DPF) и перечислены здесь: Data Privacy Framework

— Введены обязательные корпоративные правила (BCR).

— есть Standard договорных положений (SCC).

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

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

Несоответствующие требованиям:

- Отсутствует список^{трех сторон или} субпроцессоров.

- Подробные сведения о странах-получателях не приводятся.

- Страны не перечислены в качестве "адекватных стран", и отсутствуют BCR или SCC.

Пример доказательства:

В этом примере показан пример DPA из IAPP, или свидетельством может быть связанный документ со списком сторон, которым предоставлен общий доступ к данным.

Кроме того, проверка механизмы передачи данных за пределы ЕС.

Элемент управления No 13 — оценки влияния на защиту данных (DPIA)

Предоставьте доказательства того, что ваша организация проводит оценку влияния на защиту данных (DPIA)

     ИЛИ

Укажите имя оценки, связанной с конфиденциальностью и защитой данных, с которыми связана эта проверка конфиденциальности.

Намерение:

Цель этого контроля заключается в том, чтобы убедиться, что вы проводите оценку потенциальных рисков для прав и свобод людей, особенно связанных с внедрением новых технологий или новым использованием существующих технологий. (См. статью 35 GDPR)

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

Этот контроль будет оцениваться путем просмотра недавнего DPIA или соответствующей документации по оценке.

Несоответствующие требованиям:

DPIA должен содержать следующие элементы:

— определение необходимости в DPIA.

— описание предполагаемой обработки, включая область, контекст и цели.

- Оценка необходимости и пропорциональности.

— Выявление и оценка рисков.

— определение мер по снижению риска.

— записанные результаты.

Если какое-либо из указанных выше элементов отсутствует или просто выполняется на перфункторном уровне, этот элемент управления можно пометить как несоответствующий.

Пример доказательства:

Полный шаблон DPIA можно найти на веб-сайте ICO здесь dpia-template.docx

Контроль No 14 — биометрические данные

Взаимодействует ли приложение с биометрическими данными? Если да,

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

Намерение:

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

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

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

Несоответствующие требованиям:

Юридическая проверка обработки биометрических данных должна содержать следующее:

— правовая основа обработки (одна или несколько из следующих):

Согласие	Выполнение контракта	Другое юридическое обязательство
Согласие	Выполнение контракта	Другое юридическое обязательство
Жизненно важные интересы	Общественные интересы	Законный интерес

— Перечисление допустимого условия для обработки биометрических данных (одно или несколько из следующих):

Явное согласие пользователя	Занятость или социальное обеспечение
Явное согласие пользователя	Занятость или социальное обеспечение
Защита жизненно важных интересов	Допустимые действия
Персональные данные, явно обнародованные субъектом данных	Создание, осуществление или защита судебных исков
Существенный общественный интерес	Профилактическая или трудовая медицина
Интерес общественности в области общественного здравоохранения	Цели архивирования в общественных интересах, научные или исторические исследования

– Рассматривается использование альтернативных вариантов вместо биометрических данных.

Если какое-либо из указанных выше элементов отсутствует или просто выполняется на перфункторном уровне, этот элемент управления можно пометить как несоответствующий.

Пример доказательства:

Источники:

- GDPR, статья 9 . Обработка специальных категорий данных: статья 9 GDPR — обработка особых категорий персональных данных — Общий регламент по защите данных (GDPR)

- ICO "Как мы обрабатываем биометрические данные на законных основаниях?": Как мы обрабатываем биометрические данные на законных основаниях? | ICO

 

Элемент управления No 15 — Аналитика данных

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

Намерение:

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

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

Чтобы продемонстрировать наличие этого элемента управления, необходимо предоставить свидетельство с помощью графического интерфейса пользователя или ИНТЕРФЕЙСА командной строки, чтобы продемонстрировать:

— конфигурация на уровне пользователя для наименьших ограничений уровней агрегирования.

— Выборка метрик.

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

Несоответствующие требованиям:

— Пользователи не могут настроить свои уровни агрегирования как минимум до 5, или технический навык, необходимый для этого, не может быть ожидаемым от обычного пользователя.

— персональные данные присутствуют в образце метрики; например: имя, фамилия, идентификатор, номер клиента, номер телефона, адрес электронной почты, почтовый адрес, банковские реквизиты, ближайший родственник и т. д.

Пример доказательства:

Снимок экрана параметров конфигурации с конкретными сведениями.

Выборка собранных метрик. Возможно, спросите о процессе достижения анонимности.

GDPR

Большинство организаций будут обрабатывать данные, которые потенциально являются данными европейского гражданина (субъектов данных). При обработке данных ЛЮБОГО субъекта данных организации должны будут соблюдать Общий регламент по защите данных (GDPR). Это относится как к контроллерам данных (вы напрямую собираете указанные данные), так и к обработчикам данных (вы обрабатываете эти данные от имени Контроллера данных). Хотя этот раздел не охватывает все регулирование, в нем рассматриваются некоторые ключевые элементы GDPR, чтобы получить некоторую уверенность в том, что организация серьезно относится к GDPR.

Элемент управления No 16

Предоставьте доказательства, подтверждающие соблюдение прав субъекта данных, демонстрируя:

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

• Обнаружение данных и выполнение SAR. Свидетельство возможности вашей организации находить и извлекать все персональные данные, относящиеся к отдельному субъекту данных, во всех системах и репозиториях в ответ на SAR.

Намерение:

Цель этого контроля заключается в том, чтобы обеспечить наличие адекватных механизмов для субъектов данных для отправки запросов о своих персональных данных, храняхся в организации, и тщательное выполнение законных запросов. (См. статью 15 GDPR).

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

A) Уведомление о конфиденциальности должно содержать сведения о том, как создать SAR, который может использовать следующие методы:

— Использование веб-формы, предоставляемой организацией

— использование адреса электронной почты, предоставленного организацией;

— использование номера телефона или веб-чата, предоставленного организацией

- Использование надзорного органа (например, ICO в Великобритании)

Запрос подтверждения метода на месте; захватов экрана должно быть достаточно.

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

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

Запросите свидетельство процесса или рабочего процесса, которые будут использоваться для выполнения SAR, и объяснение того, как было определено, что процесс является тщательным и не пропустит никаких персональных данных, относящихся к субъекту данных.

Несоответствующие требованиям:

A) На веб-сайте организации не предоставляется никакой информации (как правило, в уведомлении о конфиденциальности).

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

Пример доказательства:

A) Ниже приведены примеры того, какие доказательства могут быть предоставлены для охвата пункта А).

— веб-форма:

Источник: Запрос на доступ к субъекту - Полицейская помощь Великобритании

— Email адрес или номер телефона:

Источник: Какой? Политика конфиденциальности — что?

- Webchat:

Источник: запрос на доступ субъекта к HMRC — GOV.UK

- через надзорный орган (например, ICO):

Источник: запрос на доступ к субъекту | ICO

B) Предоставленные артефакты доказательства Подробные рабочие процессы или описания процессов с достаточной технической детализацией, которые могли бы быть использованы для выполнения SAR.

Элемент управления No 17

ЖЕСТКИЙ СБОЙ

Предоставьте уведомление о конфиденциальности, которое должно содержать все необходимые элементы следующим образом:

• Удостоверение и контактные данные организации, а также сотрудник по защите данных (DPO), если применимо.

• Типы персональных данных, обрабатываемые организацией (имя, фамилия, номер клиента, адрес электронной почты, номер телефона и т. д.). Кроме того, источники персональных данных (например, из источника персональных данных), если организация не получила их непосредственно от субъектов данных.

• Цели обработки персональных данных.

• Законные основания для обработки персональных данных (включая законные интересы, если это применимо).

• Стороны, которыми ваша организация предоставляет доступ к персональным данным.

• Сведения о том, как долго будут храниться персональные данные.

• Сведения о правах субъектов данных:

  • Право на информирование

  • Право доступа

  • Право на исправление

  • Право на стирание

  • Право на ограничение обработки

  • Право на переносимость данных

  • Право на объект

  • Права в отношении автоматизированного принятия решений, включая профилирование

• Сведения о любой передаче персональных данных в третью страну и принятые меры предосторожности.

• Право подать жалобу в надзорный орган, предоставив контактные данные надзорного органа (например, ICO в Великобритании).

Намерение:

Цель состоит в том, чтобы обеспечить, чтобы опубликованное уведомление о конфиденциальности содержало достаточно подробных сведений, включив указанные выше элементы и принципы в соответствии с главой 3 GDPR.

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

Согласно элементу управления 10.c, согласно которому необходимо опубликовать уведомление о конфиденциальности, которое охватывает службу, включенную в сертификацию Microsoft 365. Это уведомление о конфиденциальности должно содержать элементы и принципы, выделенные выше.

Несоответствующие требованиям:

См. раздел Control 10.c.

Пример доказательства:

См. раздел Control 10.c.

HIPAA (Закон о переносимости и подотчетности медицинского страхования)

Закон о переносимости и подотчетности медицинского страхования 1996 года (HIPAA) является федеральным законодательством, применимым к американским гражданам и медицинским организациям. Важно отметить, что это законодательство также распространяется на любые организации за пределами США, которые обрабатывают медицинские данные американских граждан. Введение законодательства поручило секретарю Министерства здравоохранения и социальных служб США (HHS) разработать правила, защищающие конфиденциальность и безопасность определенных медицинских сведений. Некоторые организации могут обрабатывать данные, которые являются потенциально защищенной информацией о здоровье (ePHI), что означает индивидуально определяемую информацию о состоянии здоровья, передаваемую электронными средствами массовой информации, хранящееся на электронных носителях, или передаваемую или поддерживаемую в любой другой форме или на любом другом носителе. При обработке данных о работоспособности ЛЮБОГО субъекта данных организации должны будут соответствовать ТРЕБОВАНИЯМ HIPAA.

HIPAA имеет два законодательных акта, которые необходимо рассмотреть: "Правило конфиденциальности" или "Стандарты конфиденциальности индивидуально идентифицируемой информации о здоровье", в которых изложены национальные стандарты для защиты определенной информации о здоровье, и "Стандарты безопасности" для защиты электронной защищенной медицинской информации, также называемые "правилом безопасности". Последний устанавливает национальный набор стандартов безопасности для защиты определенных медицинских сведений, которые хранятся или передаются в электронной форме.

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

Элемент управления No 18

Предоставьте доказательства, подтверждающие соответствие вашей организации Закону о переносимости и подотчетности медицинского страхования (HIPAA), предоставив доказательства того, что:

• Уведомление о практиках конфиденциальности (NPP) и обучении сотрудников. Существует уведомление о практике конфиденциальности, а для сотрудников, подрядчиков, поставщиков и других соответствующих сторон создана программа обучения сотрудников по обработке защищенной медицинской информации (PHI) в рамках HIPAA.

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

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

Намерение:

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

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

Об этом свидетельствует предоставление установленной организацией документации, излагающей политику и процедуру HIPAA. Аналитики сертификации проверят это, чтобы убедиться, что вся информация, предоставляемая в элементе управления, будет рассмотрена.

Пример доказательства:

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

Примечание. Ожидается, что поставщик программного обеспечения предоставит доступ к фактической комплексной документации по политике и процедуре, а не просто предоставит снимок экрана.

Намерение:

Чтобы понять намерение этой подмноги и обеспечить соответствие правилу безопасности, "охваченные сущности" должны сначала знать, как определяются условия конфиденциальности, целостности и доступности в соответствии с § 164.304:

• Конфиденциальность: "свойство, в котором данные или информация не предоставляются или не раскрываются неавторизованным лицам или процессам".

• Целостность: "свойство, которое данные или сведения не были изменены или уничтожены несанкционированным образом".

• Доступность: "свойство, которое данные или сведения доступны и могут использоваться по запросу уполномоченного лица".

Цель этого требования заключается в том, чтобы организации реализовали технические меры и меры, такие как доступ, аудит, целостность и контроль передачи данных в ИТ-инфраструктуре, чтобы обеспечить конфиденциальность ePHI, сохраняя при этом ее целостность и доступность для авторизованных пользователей.

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

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

Пример доказательства: элементы управления доступом и целостностью

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

На следующем снимке экрана, взятом из одной из баз данных хранилища ePHI в Atlas Mongo, показано, что только авторизованные пользователи имеют доступ и что все учетные записи имеют уникальные идентификаторы пользователей для обеспечения подотчетности.

На первом снимку экрана показано основное расположение хранилища или кластер базы данных для ePHI.

На втором снимках экрана показано, что утвержденные пользователи имеют только те роли и доступ, которые задокументированы.

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

Каждая пользовательская роль имеет набор разрешений и область доступа.

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

Пример доказательства: элементы управления аудитом

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

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

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

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

Пример доказательства: элементы управления шифрованием и передачей

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

На следующих двух снимках экрана показано, что данные, передаваемые в хранилище, зашифрованы по умолчанию. На первом снимке экрана показано, что API данных включен с разрешениями "чтение и запись".

Проверка конечной точки ssl показывает, что передаваемые данные шифруются по протоколу TLS 1.2.

Пример подтверждения: элементы управления доступностью и восстановлением

На следующем снимку экрана показано, что кластер базы данных реплицируется в трех регионах для обеспечения доступности. Это делается по умолчанию Mongo Atlas. Кроме того, резервное копирование включено и активно.

На следующем снимок экрана показана панель мониторинга резервного копирования кластера, на которой также показано, что snapshot уже создан.

На следующих двух снимках экрана показано, что существует политика резервного копирования для выполнения запланированного резервного копирования в разные моменты времени (PIT).

Ниже указано, что существует политика хранения как для моментальных снимков, так и для восстановления на определенный момент времени (PIT).

Намерение:

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

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

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

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

Пример доказательства:

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

Пример 1. Моментальный снимок процесса оценки рисков в политике HIPAA и выполненном анализе рисков

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

Пример 2. Снимок экрана: процесс оценки рисков в политике HIPAA и выполненном анализе рисков (поддерживается в Confluence Cloud Platform)

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

Элемент управления No 19

Предоставьте доказательства того, что:

Ваша организация создала и реализовала план резервного копирования данных и план аварийного восстановления в рамках своего плана на случай непредвиденных обстоятельств в соответствии с административными гарантиями правила безопасности HIPAA в соответствии с 45 CFR §164.308(a)(7)(ii)(A) (план резервного копирования данных) и 45 CFR §164.308(a)(7)(ii)(B) (план аварийного восстановления).

Intent

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

Для ограничения использования ePHI и снижения риска раскрытия информации о ePHI необходимо создать сочетание технических и административных мер.

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

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

Пример доказательства:

На следующих снимках экрана показана Защита от потери данных Microsoft Purview (DLP), которая представляет собой интегрированную платформу, которая позволяет организациям управлять своими политиками защиты от потери данных из единого централизованного расположения.

Ниже вы можете увидеть, что включена политика "U.S. HIPAA Enhanced", которая позволяет предотвратить вставку конфиденциальных данных на определенные веб-сайты, включая личную электронную почту, запросы на создание ИИ, сайты социальных сетей и многое другое при доступе через поддерживаемый веб-браузер.

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

При выборе параметра "Изменить политику" отображается более детальное представление конкретных доступных конфигураций.

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

Политика охватывает различные типы конфиденциальных данных, а также набор классификаторов.

В следующем разделе показаны действия, настроенные для выполнения при выполнении условий, показанных на предыдущих снимках экрана.

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

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

На следующем снимку экрана показана панель конфигурации для создания оповещений при возникновении инцидента.

Намерение:

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

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

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

Пример доказательства:

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

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

Пример 1. Обучение пользователей HIPAA с помощью административного процесса

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

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

Во втором примере показано, как Можно использовать Microsoft 365 Defender для настройки и запуска обучающих кампаний.

Пример 2. Обучение пользователей HIPAA с помощью платформы моделирования атак в Microsoft 365 Defender (все пользователи)

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

Пример 3. Обучение пользователей HIPAA с помощью платформы моделирования атак Microsoft 365 Defender (отдельный пользователь)

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

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

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

Намерение:

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

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

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

Укажите полную версию плана или процедуры аварийного восстановления, которая должна охватывать план резервного копирования и план восстановления. Предоставьте фактический pdf/Word документ, если в цифровой версии, или если процесс поддерживается через онлайн-платформу, предоставьте экспорт PDF или если не удается экспортировать из-за ограничений платформы, предоставьте снимки экрана, охватывающие всю политику.

Пример доказательства:

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

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

Книги

Мердок Д. (2018) Blue Team Handbook: Incident Response Edition: сокращенное руководство по реагированию на инциденты кибербезопасности. 2-й выпуск, Publisher: CreateSpace Independent Publishing Platform.

Ссылки

• Отчеты о мошенничестве с действиями о киберпреступности Доступны: https://www.actionfraud.police.uk/ (Доступ: 10.12.2023).

• ЕС. (2021) Контрольный список GDPR для контроллеров данных Доступен по адресу ( https://gdpr.eu/checklist/ Доступ: 10.12.2023 г.).

• Microsoft. (2018) Ведение журнала событий (установщик Windows) доступно по адресу: Ведение журнала событий (доступ: 05.03.2024).

• Положительные технологии. (2020) Подход к безопасной разработке программного обеспечения Доступно по адресу: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessed:12/10/2023).

• Регламент (ЕС) 2016/679 Европейского парламента и Совета от 27 апреля 2016 года о защите физических лиц в отношении обработки персональных данных и о свободном перемещении таких данных, и отмену Директивы 95/46/EC (Общий регламент по защите данных) (Текст с релевантностью ЕЭЗ) (2016 г.) Доступно по адресу: https://www.legislation.gov.uk/eur/2016/679/contents (Доступ: 10.12.2023 г.).

• Метрики безопасности. (2020) Руководство по метрикам безопасности для соответствия требованиям PCI DSS. Доступно по адресу: https://info.securitymetrics.com/pci-guide-2020(Дата обращения: 10.12.2023).

• Уильямс J. OWASP Risk Ranking Available: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Доступно: 10.12.2023).

• Qualys. (2014) Ssl Labs: new grades for Trust (T) and Mismatch (M) Issues Available at: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Accessed: 10.12.2023).

• NIST SP800-61r2: Руководство по обработке инцидентов безопасности компьютеров доступно по адресу ( https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final доступ: 10.12.2023 г.).

• Создание конвейера CI/CD с помощью Azure Pipelines и модуля Google Kubernetes | .NET

• Google Cloud (доступ: 10.10.10.2023).

• План аварийного восстановления: https://www.sans.org/white-papers/1164/ (доступ: 10.10.2023).

• https://github.com/ (Дата обращения: 10.10.23).

• Шаблоны политики безопасности: https://www.sans.org/information-security-policy/ (доступ: 10.10.23).

• https://www.openedr.com/ (Дата обращения: 10.02.23).

• https://www.atlassian.com/software/confluence (Дата обращения: 10.10.23).

• https://www.atlassian.com/software/jira (Доступ: 28.09.23).

• План непрерывности бизнес-процессов (BCP) Табличный шаблон упражнения по адресу: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (доступ: 10/10/23).

• Сводка правила безопасности HIPAA | HHS.gov (доступ: 10.18.2023).

• Законы о конфиденциальности медицинской информации в цифровую эпоху: HIPAA не применяется - PMC (nih.gov) (доступ: 10.18.2023).

• Какова цель HIPAA? Обновление 2023 (hipaajournal.com) (Дата обращения: 10.18.2023).

• Что считается PHI в HIPAA? Обновление 2023 (hipaajournal.com) (Дата обращения: 10.18.2023).

• Политики и процедуры HIPAA (hipaajournal.com) (доступ: 10.18.2023).

• Разработка политик HIPAA & административных политик | Dash Solutions (dashsdk.com) (доступ: 10.18.2023).

• 45 CFR § 164.304 — Определения. | Электронный кодекс федеральных правил (e-CFR) | Закон США | LII

• / Институт правовой информации (cornell.edu) (дата обращения: 10.18.2023).

• Что такое соответствие HIPAA? Законы HIPAA & правила | Proofpoint UK (Дата обращения: 10.18.2023).

• Правила, правила и стандарты безопасности HIPAA (training-hipaa.net) (доступ: 10.18.2023).

• Сводка правила безопасности HIPAA | HHS.gov (доступ: 10.18.2023).

• SP 800-66 ред. 1, Вводное руководство по использованиюправила безопасности закона о переносимости и подотчетности медицинского страхования (HIPAA) | CSRC (nist.gov) (дата обращения: 10.18.2023).

• Правило безопасности | HHS.gov (доступ: 10.18.2023).

• https://www.hipaajournal.com/hipaa-encryption-requirements (Дата обращения: 10.19.2023 г.).

• https://www.hipaajournal.com/hipaa-privacy-rule/ (Дата обращения: 10.19.2023 г.).

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Дата обращения: 10.19.2023 г.).

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Дата обращения: 10.19.2023).

• Настройка шифрования — MongoDB вручную (доступ: 10.19.2023).

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Дата обращения: 10.19.2023 г.).

• Защита от потери данных Microsoft Purview: объявление о доступности нескольких возможностей

• Центр сообщества Майкрософт (доступ: 24/10/2023).

• 45 CFR § 164.308 — Административные меры безопасности. | Электронный кодекс федеральных правил (e-CFR)

• | Закон США | LII / Институт> правовой информации (cornell.edu) (дата обращения: 24/10/2023).

• Когда следует предоставлять сведения о конфиденциальности? | ICO (Дата обращения: 11.08.2023 г.).

• Как мы должны разработать нашу информацию о конфиденциальности? | ICO (Дата обращения: 11.08.2023 г.).

• Платформа подотчетности | ICO (Дата обращения: 11.08.2023).

• Требование 5.1 ISO 27001 . Обязательство руководства & | ISMS.online (доступ: 11.08.2023).

• Платформа браузера в Интернете (OBP) (iso.org) (доступ: 11.08.2023).

• Пункт 5.3 Организационные роли, обязанности и полномочия - Обучение ИСО (дата обращения: 11.08.2023 г.).

• 5.3 Роли, ответственность и полномочия (iso9001help.co.uk) (доступ: 11.08.2023).

• Отмена идентификации и повторная идентификация персональных данных в крупномасштабных наборах данных с помощью защиты конфиденциальных данных| Центр облачной архитектуры | Google Cloud (доступ: 11.08.2023).

• Отмена идентификации конфиденциальных данных | Документация по защите конфиденциальных данных | Google Cloud (доступ: 11.08.2023).

• Руководство по безопасности данных | ICO (Дата обращения: 11.08.2023).

• Международная передача данных | ICO (Дата обращения: 11.08.2023).

• Управление записями и безопасность | ICO (Дата обращения: 11.08.2023).

• ISO 27701 — Управление конфиденциальной информацией (доступ: 11.08.2023).

• ISO 27701 Privacy Information Management System (PIMS) | ISMS.Online (доступ: 11.08.2023).

Изображения и текст, взятые из документов Майкрософт

• https://www.sans.org/information-security-policy/ (Дата обращения: 18.02.21).

• Получение анализа поведения и обнаружения аномалий (доступ: 03/05/24).

• Что такое оповещения монитора Azure? (Дата обращения: 03/05/24).

• Получение аналитики поведения и обнаружения аномалий

• (Дата обращения: 03/05/24).

• Управление оповещениями системы безопасности в Microsoft Defender для облака и реагирование на них (доступ: 05.03.24).

• Управление оповещениями системы безопасности в Microsoft Defender для облака и реагирование на них (доступ: 05.03.24).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Дата обращения: 10.09.23).

• Что такое Azure Information Protection?

• Прозрачное шифрование данных для База данных SQL, Управляемый экземпляр SQL и Azure Synapse Analytics (доступ: 05.03.24).

• Краткое руководство. Создание назначения политики для идентификации несоответствующих ресурсов (accessed:03/05/24).

• Настройка Расширенной защиты от угроз для базы данных Azure SQL (доступ: 05.03.24).

• Резервное копирование и восстановление на База данных Azure для MySQL — гибкий сервер (доступ: 05.03.24).

• Инвентаризация сертификатов (доступ: 05.03.24).

• Резервное копирование и восстановление в База данных Azure для MySQL (доступ: 03/05/24).

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (доступ: 11.08.2023).

Дополнительные сведения

• Пример руководства по подтверждению — обзор
• Пример руководства по подтверждению — операции