- Как проверить целостность данных: чек-лист
- Определение целостности данных
- Что может нарушить целостность данных и как справляться с последствиями
- Обучение персонала
- Шифрование
- Отслеживание метаданных
- Ограничение физического доступа к оборудованию
- Резервное копирование данных
- Поиск и удаление дубликатов
- SSL шифрование
- Стресс-тесты
- Security аудит
- Отслеживание изменений
- Реконсиляция — проверка целостности данных в распределенных системах
- Основная идея
- Адаптеры данных
- Хранилище
- Хранилище. Реализация на базе MS SQL
- Хранилище. Сравнение значений
- Хранилище. Хэширование
- Процессор
- Благодарности
Как проверить целостность данных: чек-лист
В современном мире информация является не менее ценной, чем золото или нефть. Она перемещается и является катализатором многих процессов в глобальной экономике. Как нельзя лучше это иллюстрируют появляющиеся сегодня термины, например, “Big Data”. И точно так же, как золото или нефть, информация нуждается в защите, поэтому сохранение целостности данных стало важной задачей любого IT- отдела.
Определение целостности данных
Целостность данных — это свойство информации оставаться неизменной в промежутках между внесением санкционированных изменений.
В эпоху Интернета, этот термин стал прочно ассоциироваться с серверами и базами данных, которые уже могут размещаться в облаке и являются основными хранилищами информации.
У целостности данных есть 3 измерения:
- Безопасная передача. Возможность безопасно передавать информацию без изменений.
Например, передача данных покупателя из формы подписки в базу данных CRM.
- Безопасное хранение. Возможность статичных данных оставаться неизменными и в любой момент быть использованными по назначению.
Например, хранение данных о кредитной карте покупателя на сервере интернет-магазина.
- Верифицируемость данных. Возможность в любой момент проверить целостность информации и получить данные о любых изменениях (санкционированных и несанкционированных).
Особенно это важно для компаний, работающих с наиболее важной информацией, например, для банковских систем или медицинских организаций.
Что может нарушить целостность данных и как справляться с последствиями
Существует множество причин нарушения целостности информации, но все их можно условно разделить на 2 группы:
- Ошибки технического характера;
- Сторонние вмешательства.
С момента появления Интернета, хакеры пытались быстро и без усилий заработать, используя любые доступные уязвимости.
Исследования показали, что бренды компаний, которые стали жертвами взлома, резко теряют популярность и доверие покупателей. 15% всех опрошенных ответили, что прекратят любое взаимодействие с компанией, если она станет жертвой взлома, еще 13% заявили, что никогда не будут сотрудничать с подобной компанией.
Целостность данных важна не только с точки зрения целей бизнеса, но и для соответствия законодательству.
В России, США и странах Евросоюза существуют законодательные нормы для компаний, работающих с данными покупателей, за нарушение которых положены крупные штрафы.
Обучение персонала
Практически все данные в компании проходят через руки её сотрудников. Именно они в первую очередь ответственны за верификацию данных, поэтому с них должна начинаться любая политика безопасности в компании.
Во-первых, обмен данными внутри компании должен быть четко регламентирован. Это позволит избежать ситуаций, когда сотрудники одного отдела (например, контроля качества) могут просматривать и изменять данные, необходимые для работы другого отдела(например, отдела продаж).
Если в рамках рабочего процесса сотрудники должны обмениваться аккаунтами, предусмотрите временные пароли или менеджеры паролей (например, Enterprise Password Vault от CyberArk). Это позволит обеспечить обмен аккаунтами, при этом не давая доступа к паролям.
Во-вторых, персонал компании должен внимательно относиться к данным, и сообщать о любой подозрительной активности. Признаков определения взлома системы достаточно много, но чаще всего на них долго не обращают внимания. Такими признаками являются, например, изменённые пароли, пропажа файлов, активность аккаунта в неположенное время, несанкционированные изменения в файлах.
Шифрование
Шифрование является прекрасным способом защиты данных компании, но его эффективность ограничена, и оно значительно снижает производительность.
Шифрование данных позволяет обеспечить их безопасность даже в случае физической кражи носителя, поэтому, если риск попадания данных в чужие руки велик, этим методом нельзя пренебрегать.
В некоторых случаях, однако, шифрование бесполезно. Например, если злоумышленник для получения доступа к файлам использует данные одного из сотрудников организации. Именно поэтому нельзя ограничивать информационную защиту только средствами шифрования.
Отслеживание метаданных
Метаданные — это информация об информации. База данных, содержащая сведения о клиентах, будет включать в себя метаданные о дате внесения последних изменений и о том, с какого аккаунта эти изменения были внесены.
Важно понимать, что метаданные могут быть интересны и злоумышленникам, так как в них могут содержаться сведения типе операционной системы, версиях и паролях программ, а также адреса электронной почты сотрудников.
Ограничение физического доступа к оборудованию
Часто возникает ситуация, когда для кражи данных злоумышленнику достаточно просто скопировать их на флешку с компьютера или сервера. Именно поэтому на любом предприятии доступ к серверам и базам данных должен быть только у определённых сертифицированных специалистов.
Наиболее важные устройства, например, серверы, должны находиться в отдельных закрытых комнатах с соответствующей вентиляцией для охлаждения, а в идеале должны быть прикреплены к полу, чтобы исключить возможность физического хищения.
Такие меры могут усложнить работу системным администраторам, но безопасность данных должна являться приоритетом.
Если компания ограничена в свободном пространстве, то серверы и базы данных должны находиться под постоянным наблюдением сотрудника, которым, в зависимости от структуры компании, может быть системный администратор или менеджер.
Резервное копирование данных
Создание копии — это обязательная мера защиты для любого предприятия. Правильный ответ на вопрос “Как часто проводить резервное копирование?” Ответ: “Чем чаще, тем лучше”. Многие современные решения, например, ПО компании UNITRENDS , позволяют делать это “на лету”. Естественно, практические соображения, такие как производительность оборудования и стоимость самой услуги, существенно ограничивают возможности частого бэкапа данных. Для малого бизнеса затраты на приобретение второго сервера или на услуги сторонних компаний могут оказаться очень большими.
По иронии, некоторые компании становилась жертвами взлома именно из-за наличия резервной копии. Известны случаи, когда незащищенную копию данных компании можно было просто найти в поисковой системе.
Если резервная копия попадет не в те руки, извлечь из неё данные может быть достаточно просто.
Поиск и удаление дубликатов
В процессе работы компании часто возникает ситуация, когда важная информация копируется и хранится в папках с общим доступом или в сторонних облачных хранилищах.
Чтобы избежать попадания данных в руки преступников, важно регулярно проводить поиск и удалять дубликаты файлов. Это можно делать вручную или использовать различные программные решения.
SSL шифрование
Наличие SSL-протокола — это черта любого уважающего себя сайта. Он позволяет шифровать данные, которые передаются между клиентом и сервером, в результате чего существенно снижается риск их попадания в руки третьих лиц.
Стоимость такого сертификата невелика, поэтому любая компания должна приобрести его как можно быстрее.
Стресс-тесты
Для атаки на серверы злоумышленники часто перегружают их, заставляя обрабатывать слишком большие объемы информации. Даже без действий злоумышленников, у любого сервера есть предел вычислительной мощности, поэтому важно регулярно проводить стресс-тесты, чтобы проверять состояние сервера и его надежность в экстренной ситуации.
Security аудит
Самый лучший способ проверить безопасность данных — это провести тест в “полевых условиях”. Примерная схема заключается в том, что человек, владеющий “хакерскими” навыками должен попытаться получить доступ к системе, после чего предоставить отчет об обнаруженных уязвимостях.
В крупных компаниях такой человек может быть штатным специалистом, малый бизнес традиционно отдает эту задачу на аутсорсинг.
Существует также специальное ПО (например, Rapid7), предназначенное для проведения полного аудита инфраструктуры компании.
В рамках аудита вы должны получить ответы на вопросы:
- соблюдают ли сотрудники режим доступа к данным;
- какая информация является наиболее важной для компании;
- есть ли в системе потенциальные уязвимости;
- какие меры следует предпринять для устранения обнаруженных угроз.
Отслеживание изменений
Для безопасности данных важно отслеживать источники атак. Специальное ПО, предназначенное для этого, позволяет:
- автоматически фиксировать доступ к файлам;
- устанавливать приоритет, не позволяющий пользователям изменять записи, сделанные программой;
- отмечать любое изменение файла на временной шкале;
- пошагово воссоздать все действия, совершенные пользователем.
Информация — это основа современной экономики, поэтому её защита от посторонних глаз важна для любой компании. Методы, описанные в этой статье, должны применяться на любом предприятии. Позаботьтесь о безопасности своих данных сегодня!
Источник
Реконсиляция — проверка целостности данных в распределенных системах
При разработке и использовании распределенных систем перед нами возникает задача контроля целостности и идентичности данных между системами — задача реконсиляции.
Требования, которые выставляет заказчик — минимальное время данной операции, поскольку чем раньше расхождение будет найдено, тем легче будет устранить его последствия. Задача заметно усложняется тем, что системы находятся в постоянном движении (
100 000 транзакций в час) и добиться 0% расхождений не получится.
Основная идея
Основную идею решения можно описать следующей диаграммой.
Рассмотрим каждый из элементов отдельно.
Адаптеры данных
Каждая из систем создана для своей предметной области и как следствие описания объектов могут существенно различаться. Нам же требуется сравнить только определенный набор полей из этих объектов.
Для упрощения процедуры сравнения, приведем объекты к единому формату, написав для каждого источника данных свой адаптер. Приведение объектов к единому формату, позволяет заметно сократить объем используемой памяти, поскольку хранить мы будем только сравниваемые поля.
Под капотом у адаптера может быть любой источник данных: HttpClient, SqlClient, DynamoDbClient и т.д.
Ниже представлен интерфейс IAdapter, который требуется реализовать:
Хранилище
Реконсиляцию данных можно начинать только после того как все данные прочитаны, поскольку адаптеры могут возвращать их в произвольном порядке.
В таком случае объема оперативной памяти может не хватить, особенно если вы запускаете несколько реконсиляций одновременно, указывая большие временные интервалы.
Рассмотрим интерфейс IStorage
Хранилище. Реализация на базе MS SQL
Мы реализовали IStorage, используя MS SQL, что позволило выполнять сравнение полностью на стороне Db сервера.
Для хранения реконсилируемых значений достаточно создать следующую таблицу:
Каждая запись содержит системные поля ([id], [adapterId]) и поля, по которым осуществляется сравнение ([qty], [price]). Пару слов о системных полях:
[id] — уникальный идентификатор записи, одинаковый в обеих системах
[adapterId] — идентификатор адаптера, через который была получена запись
Так как процессы реконсиляции могут быть запущены параллельно и иметь пересекающиеся интервалы, мы создаем для каждой из них таблицу с уникальным именем. В случае если реконсиляция прошла успешно, данная таблица удаляется, в противном случае отправляется отчет со списком записей, в которых есть расхождения.
Хранилище. Сравнение значений
Представим, что у нас есть 2 множества, элементы которого имеют абсолютно идентичный набор полей. Рассмотрим 4 возможных случая их пересечения:
A. Элементы присутствуют только в левом множестве
B. Элементы присутствуют в обоих множествах, но имеют разные значения
С. Элементы присутствуют только в правом множестве
D. Элементы присутствуют в обоих множествах и имеют одинаковые значения
В конкретной задаче нам требуется найти элементы, описанные в случаях A, B, C. Получить требуемый результат можно за один запрос к MS SQL через FULL OUTER JOIN:
Вывод данного запроса может содержать 4 вида записей, отвечающих исходным требованиям
# | id | adapterid | comment |
---|---|---|---|
1 | guid1 | adp1 | Запись присутствует только в левом множестве. Случай A |
2 | guid2 | adp2 | Запись присутствует только в правом множестве. Случай С |
3 | guid3 | adp1 | Записи присутствует в обоих множествах, но имеют разные значения. Случай B |
4 | guid3 | adp2 | Записи присутствует в обоих множествах, но имеют разные значения. Случай B |
Хранилище. Хэширование
Используя хэширование по сравниваемым объектам, можно значительно удешевить операции записи и сравнения. Особенно, когда заходит речь о сравнении десятков полей.
Наиболее универсальным оказался способ хэширования сериализованного представления объекта.
1. Для хэширования мы используем стандартный метод GetHashCode(), возвращающий int32 и переопределенный для всех примитивных типов.
2. В данном случае вероятность коллизий маловероятна, поскольку сравниваются только записи имеющие одинаковые идентификаторы.
Рассмотрим структуру таблицы, используемую при данной оптимизации:
Преимущество такой структуры — это константная стоимость хранения одной записи (24 байта), которая не будет зависеть от числа сравниваемых полей.
Естественно и процедура сравнения претерпевает свои изменения и становится значительно проще.
Процессор
В данном разделе пойдет речь о классе, содержащем всю бизнес-логику реконсиляции, а именно:
1. параллельное чтение данных из адаптеров
2. хэширование данных
3. буферизованная запись значений в БД
4. выдача результатов
Более комплексное описание процесса реконсиляции можно получить, рассмотрев диаграмму последовательностей и интерфейс IProcessor.
Благодарности
Огромная благодарность моим коллегам из MySale Group за фидбек: AntonStrakhov, Nesstory, Barlog_5, Косте Кривцуну и VeterManve — автору идеи.
Источник