2.3 Определение стандартов в области безопасности данных

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

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

Классификация данных по уровням конфиденциальности — важный аспект применения метаданных. Она лежит в основе предоставления пользователям привилегий доступа к данным. Каждая организация создает или заимствует схему классификации, отвечающую ее бизнес-тре бованиям. Любой метод классификации должен быть ясным и простым в применении. Должно быть предусмотрено достаточное количество уровней конфиденциальности информации, начи ная с низкого и до самого высокого. Например, начиная с категории «Для всеобщего пользова ния» и заканчивая категорией «Строго конфиденциальная, под подписку о неразглашении» (см. раздел 1.3.12.1).

2.3.2 Определение категорий регламентирующих норм и правил

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

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

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

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

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

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

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

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

2.3.3 Определение ролей безопасности

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

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

Ролевые группы позволяют администраторам служб ИБ соотносить привилегии с ролями, а затем наделять этими привилегиями индивидуальных пользователей посредством включения их учетных записей в подходящую им по статусу и/или должности ролевую группу. Технически возможно включение одного и того же сотрудника в различные ролевые группы, но на практике этого следует избегать, чтобы не запутаться, какими привилегиями и полномочиями наделен тот или иной пользователь. По мере возможности старайтесь относить каждого пользователя только к одной ролевой группе. При этом может потребоваться создание различных пользовательских представлений каких-либо данных для разных ролевых групп, с тем чтобы пользователи каждой группы видели только те данные, которые им доступны согласно уровню привилегий и норма тивно-правовым требованиям.

Обеспечение согласованности и непротиворечивости данных при управлении пользователями

иролями — задача не из простых. Данные о пользователе (ФИО, должность, ID сотрудника и т. п.) во многих случаях избыточно хранятся в нескольких местах. Как следствие, эти «острова данных» (islands of data) часто содержат противоречивую информацию об одном и том же физическом лице, представляя различные версии «правды» (versions of the «truth»). Во избежание проблемных си туаций с целостностью данных обеспечьте централизованное управление идентификационными данными пользователей и их распределением по ролевым группам. Это обязательное требование обеспечения качества данных, без соблюдения которого эффективный контроль доступа невозмо жен. Администраторы безопасности отвечают за создание, изменение и удаление учетных записей пользователей и ролевых групп. Изменения классификации и привилегий групп, а также перевод пользователей из одной группы в другую требуют соответствующего согласования. Все изменения должны отслеживаться с помощью системы управления изменениями.

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

инасколько последовательно осуществляется их распределение.

Можно выделить два основных альтернативных подхода к определению и организации ро лей — на основе решетки (начиная с данных) или на основе иерархии (начиная с пользователей).

2.3.3.1 РЕШЕТКА НАЗНАЧЕНИЯ РОЛЕЙ

Решетку (grid) полезно использовать для сопоставления различных ролей с данными, осущест вляемого на основе уровней конфиденциальности, нормативно-правовых требований и функций пользователей. Роль «Пользователь с общим доступом» (Public User) позволяет работать со все ми нерегламентированными данными, предназначенными для всеобщего пользования (general audiences). Пользователям с ролью «Маркетинг» может быть открыт доступ к части персональной

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

Таблица 14. Пример решетки назначения ролей

2.3.3.2 ИЕРАРХИЯ НАЗНАЧЕНИЯ РОЛЕЙ

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

2.3.4 Оценка текущих рисков безопасности данных

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

чувствительность хранящихся или передаваемых данных;

требования по обеспечению защиты этих данных;

имеющиеся средства защиты этих данных.

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

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

Рисунок 65. Пример иерархии назначения ролей

В крупных организациях имеет смысл периодически прибегать к услугам «белых» хакеров, способных всесторонне проверить системы на уязвимость. Между прочим, подтверждение устойчивости системы ИБ организации к проникновениям, полученное от специалистов, — это еще и отменная реклама, а также средство поднятия репутации на рынке.

2.3.5 Внедрение механизмов контроля и процедур

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

Для обеспечения выполнения требований политики безопасности организации необходимо внедрить надлежащие механизмы (элементы) контроля (controls)1. Механизмы (элементы) кон троля и процедуры должны (как минимум) охватывать:

1 В ГОСТ Р ИСО/МЭК 27002-2012 «Информационная технология (ИТ). Методы и средства обеспечения безопасно сти. Свод норм и правил менеджмента информационной безопасности» термин «control» применительно к тематике стандарта переведен как «мера и средство контроля и управления». В данном издании применительно к этой же тематике он для краткости переводится как «механизм контроля» или «элемент контроля» (в зависимости от контек ста). — Примеч. науч. ред.

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

Например, политика «Осуществлять надлежащее ведение привилегий пользователей» может иметь контрольную цель: «Права и привилегии администратора БД и пользователей подлежат ежемесячному пересмотру и подтверждению». Процедура, отвечающая требованиям этого эле мента контроля, должна предусматривать внедрение (и сопровождение) в организации процес сов, обеспечивающих:

подтверждение выданных разрешений посредством их сверки c данными системы управле ния изменениями;

реализацию автоматизированного потока работ (workflow) по согласованию или процедуры под писания заявки в бумажной форме с целью документирования каждого запроса на изменение;

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

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

2.3.5.1 НАЗНАЧЕНИЕ УРОВНЕЙ КОНФИДЕНЦИАЛЬНОСТИ

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

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

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

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

2.3.5.2 НАЗНАЧЕНИЕ КАТЕГОРИЙ РЕГЛАМЕНТИРУЮЩИХ НОРМ И ПРАВИЛ

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

2.3.5.3 УПРАВЛЕНИЕ И ПОДДЕРЖКА БЕЗОПАСНОСТИ ДАННЫХ

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

2.3.5.3.1 КОНТРОЛЬ ДОСТУПНОСТИ ДАННЫХ / ДАТАЦЕНТРИЧНАЯ БЕЗОПАСНОСТЬ

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

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