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

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

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

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

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

Предоставьте доказательства для всего следующего:

• Убедитесь, что конфигурация TLS имеет значение TLS 1.2 или более поздней версии.

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

Намерение: 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 отключено для всех общедоступных служб, обрабатывающих веб-запросы, чтобы предотвратить CRIME (утечка сведений о коэффициенте сжатия сделана простой).

• Проверяет, включена ли служба HSTS TLS и настроена на 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

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

Намерение:

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

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

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

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

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

Обратите внимание: в предыдущих примерах полные снимки экрана не использовались, однако все снимки экрана, отправленные 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

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

• поддерживается, включая бизнес-обоснование для каждого человека.

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

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

Намерение:

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

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

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

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

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

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

Намерение:

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

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

Как правило, доказательства, предоставленные для предыдущего элемента управления, могут помочь в поддержке этого элемента управления. Если в предоставленной документации нет официального утверждения, то подтверждение может состоять из запроса на изменение, который был вызван и утвержден для доступа в рамках такого средства, как 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

Установлена, реализована ли в вашей организации система управления конфиденциальной информацией (PIM), которая:

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

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

Намерение:

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

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

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

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

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

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

Intent

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

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

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

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

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

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

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

Предоставьте доказательства процессов, чтобы показать, что:

• Выполняется минимизация личных данных.

• Удаление и удаление персональных данных выполняется в конце периода обработки.

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

• Запись о передаче личных данных из одной страны или региона в другую существует с выраженным согласием на это.

Намерение: личные данные

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

Рекомендации: личные данные

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

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

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

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

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

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

Намерение: конфиденциальность данных

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

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

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

Рекомендации: конфиденциальность данных

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

Пример доказательства: конфиденциальность данных

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

На следующем снимку экрана показана конфигурация конвейера анонимизации личных сведений. Он использует код для использования Presidio на Служба приложений Azure для вызова Presidio в качестве конечной точки REST HTTP в конвейере Фабрика данных Azure при анализе и сохранении каждого файла в качестве Хранилище BLOB-объектов Azure.

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

На последнем снимку экрана показано успешное выполнение конвейера для анонимизации личных сведений.

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

Пример доказательства: конфиденциальность данных

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

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

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

Пример доказательства: конфиденциальность данных

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

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

Намерение: элементы управления

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

Рекомендации: элементы управления

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

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

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

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

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

Обратите внимание, что если шифрование не выполняется платформой, используемой по умолчанию, и вашим собственным шифрованием

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

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

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

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

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

Пример доказательства: предотвращение передачи персональных данных и раскрытия информации

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

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

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

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

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

Намерение: записи

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

Рекомендации: записи

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

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

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

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

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

GDPR

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

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

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

• Субъекты данных могут создавать SRS.

• Убедитесь, что вы (ISV) можете определить все расположения данных субъектов данных при ответе на запрос SAR.

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

Намерение:

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

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

Укажите задокументированную процедуру обработки SAR. Пример доказательства:

В следующем примере показан задокументирован процесс обработки SAR.

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

Намерение:

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

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

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

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

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

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

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

Этот запрос подтверждает используемые учетные записи хранения. Вы можете запрашивать и удалять хранилище, большие двоичные объекты и (или) файлы с помощью Resource Graph Обозреватель (Kusto) или PowerShell (см. далее).

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

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

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

Намерение:

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

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

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

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

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

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

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

28-дневный срок хранения резервных копий в сочетании с частотой резервного копирования означает, что при выполнении SAR скользящее резервное копирование будет продолжаться не более 27 дней с учетом периода хранения, пока не будут удалены все данные пользователя.

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

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

• Сведения о сущностях (имя, адрес и т. д.)

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

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

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

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

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

  • Право субъекта данных на доступ

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

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

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

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

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

Намерение:

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

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

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

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

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

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

На изображениях уведомления о конфиденциальности показан пример политики конфиденциальности в Интернете с включенной статьей 13 GDPR.

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

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

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

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

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

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

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

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

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

• Существует политика для обработки HIPAA и HIPAA в организации для сотрудников, подрядчиков и т. д.

• IsV обеспечивает конфиденциальность, целостность и доступность ePHI, которые создаются, получаются, поддерживаются или передаются.

• Защита от любых разумно ожидаемых угроз и угроз безопасности или целостности ePHI.

Намерение:

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

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

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

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

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

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

Намерение:

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

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

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

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

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

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

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

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

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

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

На первом снимку экрана показан main расположения хранилища или кластера базы данных для 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 15

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

• Защищает от разумно ожидаемого использования или раскрытия такой информации, которая не разрешена Правилом конфиденциальности; И

• Обеспечьте соблюдение правила безопасности сотрудниками.

• План резервного копирования и аварийного восстановления данных в 164..308 (a)(7)(ii)(A) и 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.restore.co.uk/Records/Services/Magnetic-Tape-Storage (Дата обращения: 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).

• https://www.iow.nhs.uk/Downloads/Policies/Business%20Continuity%20Policy.pdf (Дата обращения: 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).

• Принцип (c): минимизация данных | ICO (Дата обращения: 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 Monitor? (Дата обращения: 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).

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

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