Цель хранилища данных — сделать большие объемы данных легкодоступными для пользователей, что позволяет пользователям извлекать информацию о бизнесе в целом. Но мы знаем, что на данные могут быть наложены некоторые ограничения безопасности, которые могут стать препятствием для доступа к информации. Если аналитик имеет ограниченное представление о данных, то невозможно получить полную картину тенденций в бизнесе.
Данные от каждого аналитика могут быть обобщены и переданы руководству, где могут быть агрегированы различные сводные данные. Поскольку совокупность сводок не может быть такой же, как и совокупность в целом, можно пропустить некоторые информационные тренды в данных, если кто-то не анализирует данные в целом.
Требования безопасности
Добавление функций безопасности влияет на производительность хранилища данных, поэтому важно определить требования безопасности как можно раньше. Трудно добавить функции безопасности после запуска хранилища данных.
На этапе проектирования хранилища данных мы должны помнить, какие источники данных могут быть добавлены позже и как это повлияет на добавление этих источников данных. Мы должны рассмотреть следующие возможности на этапе проектирования.
-
Будут ли новые источники данных требовать введения новых ограничений безопасности и / или аудита?
-
Добавлены ли новые пользователи, которые имеют ограниченный доступ к данным, которые уже общедоступны?
Будут ли новые источники данных требовать введения новых ограничений безопасности и / или аудита?
Добавлены ли новые пользователи, которые имеют ограниченный доступ к данным, которые уже общедоступны?
Такая ситуация возникает, когда будущие пользователи и источники данных недостаточно известны. В такой ситуации нам необходимо использовать знания бизнеса и цели хранилища данных, чтобы знать возможные требования.
Следующие действия затрагиваются мерами безопасности —
- Доступ пользователя
- Загрузка данных
- Перемещение данных
- Генерация запросов
Доступ пользователя
Нам нужно сначала классифицировать данные, а затем классифицировать пользователей на основе данных, к которым они могут получить доступ. Другими словами, пользователи классифицируются в соответствии с данными, к которым они могут получить доступ.
Классификация данных
Следующие два подхода могут быть использованы для классификации данных —
-
Данные могут быть классифицированы в соответствии с их чувствительностью. Высокочувствительные данные классифицируются как строго ограниченные, а менее чувствительные данные классифицируются как менее строгие.
-
Данные также могут быть классифицированы в соответствии с функцией работы. Это ограничение позволяет только определенным пользователям просматривать конкретные данные. Здесь мы ограничиваем пользователей просматривать только ту часть данных, в которой они заинтересованы и за которую несут ответственность.
Данные могут быть классифицированы в соответствии с их чувствительностью. Высокочувствительные данные классифицируются как строго ограниченные, а менее чувствительные данные классифицируются как менее строгие.
Данные также могут быть классифицированы в соответствии с функцией работы. Это ограничение позволяет только определенным пользователям просматривать конкретные данные. Здесь мы ограничиваем пользователей просматривать только ту часть данных, в которой они заинтересованы и за которую несут ответственность.
Есть некоторые проблемы во втором подходе. Чтобы понять, давайте иметь пример. Предположим, вы создаете хранилище данных для банка. Учтите, что данные, хранящиеся в хранилище данных, являются данными транзакций для всех учетных записей. Вопрос здесь в том, кому разрешено просматривать данные транзакции. Решение заключается в классификации данных в соответствии с функцией.
Пользовательская классификация
Следующие подходы могут быть использованы для классификации пользователей —
-
Пользователи могут быть классифицированы в соответствии с иерархией пользователей в организации, то есть пользователи могут быть классифицированы по отделам, разделам, группам и т. Д.
-
Пользователи также могут быть классифицированы в соответствии с их ролью, а люди сгруппированы по отделам в зависимости от их роли.
Пользователи могут быть классифицированы в соответствии с иерархией пользователей в организации, то есть пользователи могут быть классифицированы по отделам, разделам, группам и т. Д.
Пользователи также могут быть классифицированы в соответствии с их ролью, а люди сгруппированы по отделам в зависимости от их роли.
Классификация на основе кафедры
Давайте рассмотрим пример хранилища данных, где пользователи из отдела продаж и маркетинга. Мы можем обеспечить безопасность с точки зрения компании сверху вниз, причем доступ сосредоточен на разных отделах. Но могут быть некоторые ограничения для пользователей на разных уровнях. Эта структура показана на следующей диаграмме.
Но если каждый отдел получает доступ к разным данным, мы должны разработать безопасный доступ для каждого отдела в отдельности. Это может быть достигнуто за счет витрин данных отдела. Поскольку эти витрины данных отделены от хранилища данных, мы можем применять отдельные ограничения безопасности для каждого киоска данных. Этот подход показан на следующем рисунке.
Классификация на основе роли
Если данные, как правило, доступны для всех отделов, полезно следовать иерархии доступа к ролям. Другими словами, если к данным обычно обращаются все отделы, тогда применяются ограничения безопасности в соответствии с ролью пользователя. Иерархия доступа к ролям показана на следующем рисунке.
Требования к аудиту
Аудит является подмножеством безопасности, дорогостоящей деятельностью. Аудит может привести к значительным накладным расходам в системе. Чтобы вовремя завершить аудит, нам требуется больше оборудования, и поэтому рекомендуется, по возможности, отключать аудит. Требования аудита могут быть классифицированы следующим образом:
- связи
- Отключения
- Доступ к данным
- Изменение данных
Примечание. Для каждой из вышеупомянутых категорий необходимо провести аудит успеха, неудачи или того и другого. С точки зрения безопасности, аудит сбоев очень важен. Аудит отказов важен, потому что они могут выделить несанкционированный или мошеннический доступ.
Требования к сети
Безопасность сети так же важна, как и другие ценные бумаги. Мы не можем игнорировать требования безопасности сети. Нам нужно рассмотреть следующие вопросы —
-
Нужно ли шифровать данные перед их передачей в хранилище данных?
-
Существуют ли ограничения на какие сетевые маршруты могут принимать данные?
Нужно ли шифровать данные перед их передачей в хранилище данных?
Существуют ли ограничения на какие сетевые маршруты могут принимать данные?
Эти ограничения должны быть тщательно рассмотрены. Ниже приведены моменты, которые нужно помнить —
-
Процесс шифрования и дешифрования увеличит накладные расходы. Это потребовало бы большей вычислительной мощности и времени обработки.
-
Стоимость шифрования может быть высокой, если система уже является загруженной системой, поскольку шифрование несет исходная система.
Процесс шифрования и дешифрования увеличит накладные расходы. Это потребовало бы большей вычислительной мощности и времени обработки.
Стоимость шифрования может быть высокой, если система уже является загруженной системой, поскольку шифрование несет исходная система.
Движение данных
Существуют потенциальные последствия для безопасности при перемещении данных. Предположим, нам нужно передать некоторые ограниченные данные в виде плоского файла для загрузки. Когда данные загружаются в хранилище данных, возникают следующие вопросы:
- Где хранится плоский файл?
- У кого есть доступ к этому дисковому пространству?
Если мы говорим о резервном копировании этих плоских файлов, возникают следующие вопросы:
- Вы резервное копирование зашифрованных или дешифрованных версий?
- Нужно ли делать эти резервные копии на специальные ленты, которые хранятся отдельно?
- У кого есть доступ к этим лентам?
Также необходимо учитывать некоторые другие формы перемещения данных, такие как наборы результатов запроса. Вопросы, поднятые при создании временной таблицы, следующие:
- Где находится этот временный стол?
- Как вы делаете такую таблицу видимой?
Мы должны избегать случайного нарушения требований безопасности. Если пользователь с доступом к ограниченным данным может создавать доступные временные таблицы, данные могут быть видны неавторизованным пользователям. Мы можем преодолеть эту проблему, имея отдельную временную область для пользователей с доступом к ограниченным данным.
Документация
Требования аудита и безопасности должны быть надлежащим образом задокументированы. Это будет рассматриваться как часть оправдания. Этот документ может содержать всю информацию, полученную от —
- Классификация данных
- Пользовательская классификация
- Требования к сети
- Требования к перемещению и хранению данных
- Все проверяемые действия
Влияние безопасности на дизайн
Безопасность влияет на код приложения и сроки разработки. Безопасность влияет на следующую область —
- Разработка приложения
- Дизайн базы данных
- тестирование
Разработка приложения
Безопасность влияет на общую разработку приложений, а также на разработку важных компонентов хранилища данных, таких как менеджер нагрузки, менеджер хранилища и менеджер запросов. Диспетчер загрузки может потребовать проверки кода для фильтрации записей и размещения их в разных местах. Также могут потребоваться дополнительные правила преобразования, чтобы скрыть определенные данные. Также могут быть требования дополнительных метаданных для обработки любых дополнительных объектов.
Чтобы создать и поддерживать дополнительные представления, менеджеру хранилища может потребоваться дополнительный код для обеспечения безопасности. Дополнительные проверки, возможно, должны быть закодированы в хранилище данных, чтобы предотвратить его одурачивание для перемещения данных в место, где они не должны быть доступны. Диспетчер запросов требует изменений для обработки любых ограничений доступа. Диспетчер запросов должен знать обо всех дополнительных представлениях и агрегатах.
Дизайн базы данных
На структуру базы данных также влияет, потому что, когда меры безопасности осуществляются, увеличивается количество представлений и таблиц. Добавление безопасности увеличивает размер базы данных и, следовательно, увеличивает сложность проектирования и управления базой данных. Это также увеличит сложность плана управления резервным копированием и восстановления.
тестирование
Тестирование хранилища данных — сложный и длительный процесс. Повышение безопасности хранилища данных также влияет на сложность времени тестирования. Это влияет на тестирование следующими двумя способами —
Это увеличит время, необходимое для интеграции и тестирования системы.
Добавлена функциональность для тестирования, которая увеличит размер пакета тестирования.