какие еще примеры ненадежного хранения данных вы можете привести
Почему облачные хранилища считают ненадежными и как это исправить
Угроза коронавируса вынудила множество компаний переводить своих сотрудников на удаленный режим работы. Кроме вопроса организации рабочего процесса в новых условиях, особенно остро встал вопрос обеспечения безопасного доступа к данным. Решить эти проблемы призваны облачные сервисы. Однако многочисленные исследования показывают, что компании настороженно относятся к возможности использовать облако для хранения информации. Директор по информационной безопасности ИТ-холдинга ТalentТech Иван Дмитриев рассказывает, почему опасения по поводу облачных сервисов — миф и как переход на такие сервисы поможет вашему бизнесу.
Облачные хранилища ненадежны — миф или горькая правда?
Когда речь заходит о применении облачных хранилищ в бизнесе, мы наблюдаем сильную поляризацию мнений, об этом говорят результаты исследования PC Week. Несмотря на то, что существенная часть респондентов — 47% — ожидает от внедрения облачных решений то, что они действительно могут дать — сокращение затрат на ИТ, не все уверены в том, что их бизнес-процессы будут поддерживаться при этом в полном объеме.
Кроме того, 61% опрошенных отмечает, что более широко использовать облачные услуги им мешает риск прекращения деятельности облачного провайдера, 49% при этом выделяют отсутствие адекватной финансовой ответственности провайдера за ненадлежащую работу облачного сервиса. Но с провайдера в случае ошибки или невыполнения договоренностей можно взыскать компенсацию, а кто ответит за внутренние сервисы?
60% респондентов также смущает перспектива передачи ответственных приложений и данных внешним дата-центрам. Это тоже миф, ведь утечки происходят не только в облачных сервисах, но внутренние эксцессы не попадают в широкое информационное поле, поэтому мы слышим о них реже.
Вообще, плотность фокусной работы команды инфобезопасников над сервисом у облачных провайдеров выше, чем у внутренних решений. По статистике, на 1 500–2 000 сотрудников в компании приходится один сотрудник функции ИБ, но нет данных, сколько внутренних сервисов он при этом контролирует. Ответственные облачные провайдеры поддерживают плотность на более высоком уровне, ведь они рискуют своим бизнесом. Задача заказчика: убедиться, что провайдер осознает все возможные риски.
Способы исключить опасения
Перед анализом вышеперечисленных опасений стоит отметить, что главная цель облачных сервисов заключается в упрощении рабочих процессов компании, которая достигается за счет оперативности предоставления данных. Например, сервис Potok за счет сбора всех данных в едином окне ускоряет процесс найма до 45%, как это было при работе с финансовым институтом ДОМ.РФ.
Во избежание рисков со стороны облачного провайдера необходимо соблюдать несколько простых правил. Во-первых, выбирайте надежную компанию с известным именем, которая активно инвестирует в свои облачные решения, обеспечение безопасности и работает на российском рынке. При этом мы, например, обеспечиваем изоляцию и криптографическое преобразование данных с целью исключения несанкционированного доступа к информации TalentTech и его клиентов со стороны персонала заказчика.
Во-вторых, детально оцените предлагаемый провайдером уровень сервиса (SLA). Он должен включать гарантированное время доступности, порядок резервного копирования, обязанность обеспечения доступности информации при форс-мажоре. В-третьих, проанализируйте риски конфиденциальности и доступности данных при переходе на облачный сервис, а также меры управления, которые предлагает провайдер.
При переходе на работу в облако оцените, насколько ваши требования к безопасности соответствуют тому, что предлагает облачная система. Компания-провайдер должна обеспечивать должный контроль рисков целостности, конфиденциальности и доступности принадлежащей вам информации. Мы в TalentTech используем современные средства для анализа защищенности наших продуктов (Qualys, Nessus, App Screener, Supply chain security) и принимаем организационные меры по выстраиванию процесса безопасной разработки и CI/CD-процессов.
Кроме того, для успеха облачного сервиса в России ЦОД, который обеспечивает его работу, должен находиться на территории страны и соответствовать необходимому для сервиса уровню защищенности персональных данных, согласно требованиям ФЗ-152 и приказу ФСТЭК № 21. Провайдер должен предъявить для подтверждения соответствия свой аттестат или заключение, выданное компанией-лицензиатом ФСТЭК. Например, все наши продукты проходят на ежегодной основе аудит мер по защите конфиденциальной информации с привлечением компании-лицензиата.
Риски неизбежны, но управляемы
В связи с переходом на удаленную работу в любом случае увеличиваются риски, связанные с информационной безопасностью: до сих пор многие механизмы защиты от потенциальных цифровых угроз строились на уровне сети компании, а теперь нужно прибегать к другим мерам.
В современных условиях информация находится в руках сотрудников, которые работают удаленно. Это не критично, но пересмотреть подход к защите конфиденциальных данных необходимо. Сотрудники компании теперь выходят на первую линию обороны от киберугроз и должны обладать навыками основ инфобезопасности, работы с данными и понимать риски, связанные с этим. Универсального рецепта для решения связанных с безопасностью проблем нет, однако есть ряд общих правил, соблюдая которые, вы точно сократите риски:
Системы хранения данных: как выбирать?!
Проект любой сложности, как ни крути, сталкивается с задачей хранения данных. Таким хранилищем могут быть разные системы: Block storage, File storage, Object storage и Key-value storage. В любом вменяемом проекте перед покупкой того или иного storage-решения проводятся тесты для проверки определённых параметров в определённых условиях. Вспомнив, сколько хороших, сделанных правильно растущими руками проектов прокололись на том, что забыли про масштабируемость, мы решили разобраться:
Отказоустойчивость
Самая важное свойство системы хранения данных – это то, что система призвана СОХРАНЯТЬ данные без каких-либо компромиссов, то есть обеспечивать максимальную доступность и ни в коем случае не потерять даже малой их части. Почему-то очень многие задумываются о производительности, цене, но мало внимания уделяют надежности хранения данных.
Для обеспечения отказоустойчивости в случае сбоя существует одна-единственная техника – резервирование. Вопрос в том, на каком уровне применяется резервирование. С некоторым грубым упрощением, можно сказать, что уровня два: Hardware и Software.
Резервирование на уровне Hardware давно зарекомендовало себя в Enterprise-системах. SAN/NAS коробки имеют двойное резервирование всех модулей (два, а то и три блока питания, пара плат «мозгов») и сохраняют данные одновременно на нескольких дисках внутри одной коробки. Лично я метафорически представляю это себе как очень безопасную кружку: максимально надежную для сохранения жидкости внутри, с толстыми стенками и обязательно с двумя ручками на случай, если одна из них сломается.
Резервирование на уровне Software только начинает проникать в Enterprise-системы, но с каждым годом отъедает все больший и больший кусок у HW решений. Принцип тут прост. Такие системы не полагаются на надежность железа. Они считают, что оно априори ненадежно, и решают задачи резервирования на уровне ПО, создавая копии (реплики) данных и храня их на физически разном железе. Продолжая аналогию с чашками, это — когда есть несколько совершенно обычных чашек, и ты разлил чай в обе, вдруг одна разобьется.
Таким образом, SW решения не требуют дорогостоящего оборудования, как правило, более выгодны, но при этом обеспечивают ровно такую же отказоустойчивость, хотя и на другом уровне. Их также легче оптимизировать, например, разносить данные на разные сайты, выполнять балансировку, менять уровень отказоустойчивости, линейно масштабировать при росте кластера.
Расскажу, как решается вопрос резервирования на примере Parallels Cloud Storage (PStorage). PStorage не имеет привязки к какому-либо вендору железа и способен работать на совершенно обычных машинах, вплоть до настольных PC. Мы не доверяем железу, поэтому архитектура PStorage рассчитана на потерю любого физического сервера целиком (а не только отдельного диска). Все данные в Parallels Cloud Storage хранятся в нескольких копиях (репликах). При этом PStorage никогда не хранит более одной копии на физическом сервере/стойке/комнате (как захотите). Мы рекомендуем хранить 3 копии данных, чтобы быть защищенным от одновременного сбоя сразу двух серверов/стоек.
Комментарий: на рисунке показан пример кластера, хранящего данные в двух копиях.
Скорость восстановления данных
Что происходит, если один из дисков выходит из строя?
Для начала рассмотрим обычный HW RAID1 (mirror) из двух дисков. В случае выпадения одного диска, RAID продолжает работать с оставшимся, ожидая момента замены сломавшегося диска. Т.е. в это время RAID уязвим: оставшийся диск хранит единственную копию данных. У одного из наших клиентов был случай, когда в их дата-центре проводили ремонт и пилили металл. Стружки летели прямо на работающие сервера, и в течение нескольких часов диски в них стали вылетать один за другим. Тогда система была организована на обычных RAID, и в результате провайдер потерял часть данных.
Сколько времени система находится в уязвимом состоянии — зависит от времени восстановления. Эту зависимость описывает следующая формула:
= 1 / T^2 * С, где T – это время восстановления, а the mean time to data loss (MTTDL) — среднее время наработки до потери данных, С — некий коэффициент.
Итак, чем быстрее система восстановит необходимое количество копий данных, тем меньше вероятность потерять данные. Здесь мы даже опустим тот факт, что для начала процесса восстановления HW RAID администратору нужно заменить дохлый диск на новый, а на это тоже нужно время, особенно если диск нужно заказывать.
Для RAID1 время восстановления – это время, за которое RAID контроллер перельет данные с рабочего диска на новый. Как легко догадаться, скорость копирования будет равна скорости чтения/записи HDD, то есть примерно 100 MB/s, если RAID контроллер совершенно не нагружен. А если в это время RAID котроллер грузят извне, то скорость будет в несколько раз ниже. Вдумчивый читатель проведет аналогичные расчёты для RAID10, RAID5, RAID6 и придет к выводу, что любой HW RAID восстанавливается со скоростью не выше скорости одного диска.
SAN/NAS системы почти всегда используют аналогичный обычному RAID подход. Они группируют диски и собирают из них RAID. Собственно, скорость восстановления такая же.
На Software уровне гораздо больше возможностей для оптимизации. Например, в PStorage данные распределяются по всему кластеру и по всем дискам кластера, и в случае выхода из строя одного из дисков репликация начинается автоматически. Здесь не нужно ждать, когда администратор заменит диск. Кроме того, в репликации участвуют все диски кластера, поэтому скорость восстановления данных намного выше. Мы записывали данные в кластер, отключали один сервер из кластера и замеряли время, за которое кластер восстановит недостающее количество реплик. На графике результат для кластера из 7/14/21 физической ноды с двумя SATA дисками по 1TB. Кластер собран на 1GB сети.
Если использовать 10Gbit сеть, то скорость будет еще выше.
Комментарий: Здесь нет ошибки в том, что на 1Gbit сети скорость восстановления кластера из 21 сервера — почти гигабайт в секунду. Дело в том, что данные, сохранённые в Parallels Cloud Storage, распределены по дискам кластера (некий stripe в масштабе кластера), таким образом, мы получаем возможность параллельно производить копирование данных с разных дисков на разные. То есть нет единой точки владения данными, которая могла бы быть узким местом теста.
Полный сценарий теста можно найти в этом документе, при желании вы сможете его повторить самостоятельно.
Как правильно тестировать производительность — советы
Колонки «PCS+SSD» показывают производительность того же кластера, но с SSD-кешированием. PStorage имеет встроенную возможность использовать локальные SSD для write-журналирования, read-кеширования, что позволяет в несколько раз превзойти производительность локальных вращающихся дисков. Также SSD диски могут быть использованы для создания отдельного слоя (tier) с большей производительностью.
Выводы
О консистентности данных мы планируем поговорить подробнее в отдельном посте.
Самые безопасные облачные хранилища 2021 года
Большинство обладателей компьютеров и мобильных устройств уже не один год пользуются облачными хранилищами данных. Это могут быть Google Drive, Microsoft OneDrive, Dropbox. Это лишь несколько из множества популярных сервисов облачного хранения данных. Среди них есть немало разнообразных и недорогих вариантов. Когда вы сделали выбор, у вас появляется возможность получать доступ к своим файлам из любого места и возможность сохранять их на тот случай, если с компьютером или мобильным устройством что-то случится. Тогда вы сможете скачать эти файлы из облака.
Кто-то выбирает облачные хранилища по тому, сколько дискового пространства предлагается там бесплатно. Кому-то важна совместимость с установленными у них программами и сервисами. Для кого-то важнее всего конфиденциальность и такие люди ищут наиболее надёжные сервисы.
Зачем пользоваться облачным хранилищем?
Многие популярные облачные хранилища довольно удобные, но у них есть критический недостаток для тех, кто ценит свою конфиденциальность. Это вероятность того, что посторонние смогут получить доступ к вашим файлам.
Это утверждение может показаться странным. Во всех сервисах применяются надёжные алгоритмы шифрования данных. При передаче данные тоже шифруются. В чём же может быть опасность?
Шифрование данных защищает их от посторонних. Если хакер перехватит ваш трафик, он не сможет расшифровать данные. В отличие от самого сервиса облачного хранения.
Большинство этих сервисов шифруют пользовательские данные сами. Это значит, что у них есть ключи шифрования и они могут как зашифровать данные, так и расшифровать их. Пользователям остаётся только надеяться, что сервисы не будут заглядывать в их файлы. Также придётся доверить сервисам хранение ключей шифрования, чтобы их не украли злоумышленники. Ещё надо надеяться, что ваши данные не будут расшифрованы и вручены властям, если последует такой запрос.
Единственный способ сохранить свои данные в облачном хранилище заключается в правильном выборе сервиса.
По каким параметрам можно признать облачные хранилища безопасными?
Секрет надёжности облачных хранилищ заключается в шифровании. В первую очередь в том, кто контролирует ключи шифрования и дешифрования данных.
В приведённых в этой статье примерах провайдер облачного хранения отвечает за шифрование и дешифрование ваших данных. Поэтому именно он хранит у себя ключи шифрования.
Сервисы облачного хранения данных используют разные методы защиты. Данные могут сохраняться в безопасных помещениях с вооружённой охраной и биометрическими замками, словно в фильмах про Джеймса Бонда. Они могут быть зашифрованы последними алгоритмами, с которыми не справятся даже суперкомпьютеры.
Вопросы и ответы о безопасных облачных хранилищах
При выборе лучшего сервиса облачного хранения данных, когда вам нужна защита и конфиденциальность, могут возникнуть некоторые вопросы. В этой статье приведены ответы на них.
Важно ли, в какой стране работает сервис?
Страна расположения сервиса может играть большую роль. В разных странах разные законы, которые касаются передачи и хранения данных в интернете. Законы в некоторых странах уважают конфиденциальность пользователей больше, чем законы других стран. Страны вроде Швейцарии обладают законами, которые строго защищают персональные данные. У стран вроде США или Великобритании репутация в плане защиты конфиденциальности хуже.
Для облачных хранилищ страна размещения не так важна, как для других сервисов. Причина в том, что сервис облачного хранения не всегда может расшифровать ваши данные. Если ключи шифрования у вас, то данные защищены. Даже если сервис получает указания передать ваши данные полиции или если хакеры взломают хранилище, они не смогут прочитать ваши данные.
Это не всегда означает, что сервис ничего не знает о тех данных, которые вы храните в нём. В зависимости от принципов работы защищённого облачного хранилища сервис может иметь доступ к следующей информации:
Пользователю необходимо продумать защиту от угроз, чтобы данные не попали в чужие руки. Нужно принимать во внимание, как страна расположения сервиса влияет на эти угрозы, и только потом выбирать сервис.
Играет ли роль страна, где непосредственно хранятся данные.
Сервис может быть зарегистрирован в одной стране, а физически данные располагаются в другой. Например, для Sync.com в обоих случаях это Канада. MEGA располагается в Новой Зеландии и там же может хранить данные. Или же хранит их в неуказанных европейских странах, где якобы есть адекватный уровень защиты в соответствии со статьёй 45 GDPR. Решение о том, где именно будут храниться данные, принимается на основе вашего местонахождения.
Почему важно, в какой стране хранятся данные? Местные законы регулируют работу серверов, которые находятся на территории страны. Представьте, что какой-то сервис облачного хранения данных имеет штаб-квартиру в Швейцарии, но хранит данные в Китае. Китай считается одной из наиболее опасных стран в плане конфиденциальности. Местные законы будут регулировать деятельность серверов с вашими данными и компания должна будет подчиняться им, а не безопасным швейцарским законам.
Как лучше всего защитить данные в надёжном облачном хранилище?
Существуют разные подходы к защите данных в облачных хранилищах. Нужно принимать во внимание три фактора: данные в процессе передачи, данные при хранении в облаке и данные на вашем устройстве. В процессе передачи данные отправляются с вашего компьютера, смартфона или ноутбука на сервер и в обратном направлении. В остальных случаях данные хранятся на сервере или на вашем устройстве.
Данные в процессе передачи
Чтобы система считалась надёжной, данные в процессе передачи должны быть защищены одним из протоколов, чтобы никто не мог при перехвате прочитать их. При передаче данных в интернете обычно используется шифрование TLS/SSL. Оно применяется, прежде чем данные отправляются в интернет, и снимается, когда данные пришли в облачное хранилище. Это же происходит при передаче данных в обратном направлении.
Шифрование TLS/SSL обеспечивает достаточно безопасную передачу данных, но оно не работает, когда данные прибыли в пункт назначения. Если отправляемые вами в облачное хранилище данные не были зашифрованы до того, как к ним применяется шифрование TLS/SSL, после прибытия данные не зашифрованы и их можно прочитать.
Примечание: данные могут передаваться в двух окружениях. Это могут быть публичные сети вроде интернета и частные сети вроде локальной сети у вас дома или на работе. Обычно частные сети являются более защищёнными по сравнению с общедоступными. Некоторые защищённые сервисы облачного хранения данных позволяют хранить ваши файлы на собственном оборудовании внутри частной сети, что может усилить их безопасность.
Данные при хранении
Когда информация не передаётся, она где-то хранится. Когда вы храните свои файлы в облачном хранилище, они находятся на находящихся где-то серверах. Чтобы данные были защищены, к ним должен быть закрыт неавторизованный доступ. Защита может быть физической и процедурной. Серверы должны находиться в безопасном месте и у посторонних не должно быть доступа к ним. Многие сервисы облачного хранения данных обеспечивают такую защиту.
У такого типа безопасности проблема заключается в том, что необходимо доверять защиту ваших данных сервису. Если их процедуры безопасности не сработают или кто-то проникнет в место хранения файлов, ваши данные могут попасть в чужие руки.
Более безопасным вариантом хранения данных является их шифрование перед отправкой на серверы. Прочитать такие данные сможет только тот, кто сумеет их расшифровать. Обычно применяется алгоритм шифрования AES-256.
Используйте шифрование TLS/SSL при передаче данных и AES-256 или похожий современный и надёжный алгоритм шифрования данных при хранении. Это будет почти максимально возможная защита.
Кто хранит ключи от ваших данных?
Зашифровать и расшифровать данные может только тот, у кого есть ключи шифрования. Во многих случаях ключи шифрования находятся в сервисе облачного хранения. Сервис использует протоколы TLS/SSL для передачи данных, затем применяет ключ шифрования и сохраняет данные на своих серверах. Это удобно, но вы должны доверять этому сервису защиту ваших данных.
Более безопасным подходом является самостоятельное хранение ключей шифрования. Самые надёжные системы не знают ключей шифрования. Приложение на вашем устройстве использует ключи для шифрования данных перед их отправкой на сервер и для дешифрования при получении данных с сервера. На самом сервере ключей нет.
Так вы не обязаны доверять кому-то хранение ваших ключей шифрования. Нужно только доверять приложению сервиса, что оно не отправит ключи шифрования на сервис. Если это приложение с открытым исходным кодом и достаточно популярное, можно быть почти уверенным, что никаких подвохов не будет. Разбирающиеся в программировании энтузиасты проверяют исходный код таких приложений и анализируют все их возможности.
Также нужно подумать о безопасности хранения данных на устройстве. Большинство сервисов облачного хранения данных, даже самые надёжные, защищают данные только тогда, когда они покинули ваше устройство. Если кто-то получит доступ к устройству, он получит и доступ к вашим данным, если они не зашифрованы.
В NordLocker находящиеся в облачном хранилище данные зашифрованы и на пользовательских устройствах. Для их расшифровки нужно выполнить вход в учётную запись NordLocker. Шифрование данных на устройстве пользователя обеспечивает дополнительный уровень защиты.
Такие системы, где только пользователь может шифровать и дешифровать свои данные, называются сквозным шифрованием. Если вы не используете сервис, где данные сохраняются в собственной защищённой частной сети, для обеспечения максимальной надёжности требуется некоторая форма сквозного шифрования.
Зачем платить, если существуют бесплатные облачные хранилища?
Если у вас нет лишних денег, использование бесплатного тарифного плана облачного хранилища кажется лучшим вариантом. Несмотря на привлекательность, есть несколько причин купить платную подписку вместо использования бесплатного тарифа.
Всегда рекомендуется сначала попробовать бесплатный тариф сервиса, прежде чем принимать решение о покупке. Если же у вас достаточно важные данные, которые необходимо защищать как можно лучше, стоит приобрести платный тариф.
Следует ли использовать VPN при работе с облачным хранилищем?
Безопасные облачные хранилища призваны защищать пользовательские данные, но это не означает, что они не собирают никакой информации о пользователях. Многие ведут записи относительно пользовательской активности в сервисе. Могут записываться дата и время входа в учётную запись, как долго вы там находились, IP-адрес и т.д.
Лучшие практики по безопасности хранилищ данных
В статье рассматриваются ключевые угрозы, связанные с информационными хранилищами
В статье рассматриваются ключевые угрозы, связанные с информационными хранилищами, даются рекомендации по защите и затрагиваются вопросы соответствия законодательству.
Практики по безопасности хранилищ данных подразумевают защиту как инфраструктуры (локальных /внешних датацентров и облаков), так и хранимой информации. Спектр решаемых проблем достаточно широк, начиная от случайной или преднамеренной порчи информации и заканчивая неавторизированным доступом. Тема критически важная, поскольку большинство утечек данных в конечном счете сводятся к проблемам в области безопасности информационных хранилищ.
Хорошо спроектированная система безопасности также предусматривает соответствие разным нормативным положениями, как, например, PCI-DSS (Payment Card Industry Data Security Standard; Стандарт безопасности в индустрии платежных карт) или GDPR (General Data Protection Regulation, Общий регламент по защите данных), используемым в Евросоюзе. Все чаще компании в сфере безопасности стали разрабатывать решения, помогающие соответствовать подобным регламентам. В качестве примера можно привести растущий рынок GDPR решений.
В целом надежная система безопасности хранилища данных минимизирует риск кражи, несанкционированного раскрытия, подделки и случайной / преднамеренной порчи информации. Кроме того, в такой системе как правило внедрены средства, повышающие прозрачность и достоверность данных.
Угрозы безопасности хранилищ данных
Перед реализацией системы безопасности хранилища данных важно понимать типы угроз, с которыми может столкнуться компания.
В целом все факторы делятся на две категории: внешние и внутренние.
Хакеры, кибермошенники, организованные преступные группировки.
Конкуренты, занимающиеся промышленным шпионажем.
Инсайдеры с нечистоплотными помыслами.
Плохо обученный или безответственный персонал.
Пожары, наводнения и другие катастрофы природного характера.
Перебои с электроэнергией.
Принципы безопасности хранилищ данных
На самом высоком уровне система безопасности хранилища данных должна быть построена на трех принципах: конфиденциальности, целостности и доступности.
Конфиденциальность: несанкционированный доступ к данным должен быть исключен как по сети, так и локально. Это ключевой принцип, позволяющий предотвратить утечку информации.
Целостность: этот принцип в контексте безопасности означает, что данные должны быть защищены от подделки и несанкционированных изменений.
Доступность: в контексте безопасности следование этому принципу минимизирует риск выхода из строя или недоступности хранилища как намеренно – например, через DDoS атаку – так и случайно во время стихийного действия, перебоев с электроэнергией или механической поломки.
Как защитить хранилище данных
Стандарт ISO/IEC 27040 в области безопасности информационных хранилищ предусматривает использование физических, технических и административных мер для защиты систем хранения и инфраструктуры вместе с хранимой информацией. По своей природе меры контроля могут быть превентивными, розыскными, корректирующими, сдерживающими, восстанавливающими или компенсирующими.
Согласно SNIA (Storage Networking Industry Association; Ассоциация сетевых технологий хранения), основная суть стандарта ISO/IEC 27040 – наилучшие практики, позволяющие реализовать безопасности систем хранения на базовом уровне.
Меры безопасности на физическом уровне предусматривают защиту инфраструктуры и данных от физического неправомерного доступа и могут включать:
Найм персонала для мониторинга дата центров и хранилищ.
CCTV мониторинг (Сlosed Circuit Television; Система телевидения замкнутого контура) с сохранением видео.
Использование систем доступа на базе биометрии / смарт-карт и турникетов с защитой от проникновения нескольких лиц одновременно и обратного хода, которые разрешают проходить только одному человеку после аутентификации.
Мониторинг внутреннего пространства при помощи датчиков температуры и дыма.
Использование альтернативных источников питания (например, запасного генератора).
Меры безопасности на техническом уровне включают в себя многие процедуры, знакомые ИТ специалистам, как, например, защита сетевого периметра, системы обнаружения вторжений, фаерволы и антивирусы.
В контексте защиты хранилищ данных рекомендуется предпринять следующие меры:
Аутентификация пользователей и контроль доступа: в плане безопасности информационных хранилищ SNIA рекомендует уделять особое внимание аутентификации пользователей и контролю за доступом. Во многих коммерческих системах безопасности реализована защита инфраструктуры и самих данных. Кроме того, лучшие практики предусматривают реализацию следующих мер, при внедрении подобных систем:
Изменение всех стандартных учетных записей.
Избегание совместного использования учетных записей, отследить которые сложно или невозможно.
Назначение ровно таких прав, которые нужны для выполнения роли.
Изменение или снятие прав при увольнении или смены роли пользователя.
Анализ трафика: одна из наиболее действенных мер в контексте безопасности хранилищ – профилирование доступа к данным и отслеживание паттернов поведения с целью детектирования аномальной или подозрительной активности для последующего более тщательного исследования. Эта задача решается при помощи приложений для поведенческого анализа (user and entity behavior analytics; UEBA), которые все чаще становятся частью решений SIEM (security information and event management).
Мониторинг и отчетность: SNIA рекомендует внедрять разные возможности, связанные с мониторингом и отчетностью, включая разные приложения и системные журналы для детектирования и более глубокого понимания нарушений в области безопасности с целью предотвращения подобных инцидентов в будущем.
Защита интерфейсов управления: многие организации внедряют меры по защите инфраструктуры хранилища и данных от неавторизированного доступа, но забывают обезопасить системы управления. Соответственно, злоумышленник может наделить себя нужными правами доступа или расширить уже существующие привилегии для доступна к данным.
Приведенный перечень технических мер ни в коей мере не является исчерпывающим. Также следует внедрять другие средства безопасности, включая:
Надежное шифрование как в стационарных хранилищах, так и во время передачи данных по сети в связке с эффективной системой управления ключами.
Защиту конечных узлов: настольных компьютеров, ноутбуков и других устройств, у которых есть доступ к данным для минимизации риска установки вредоносов, могущих скомпрометировать хранимые данные.
Специальные меры для защиты баз данных, содержащих кредитные карты и другую ценную коммерческую конфиденциальную информацию. Наилучшие практики безопасности включают усиление защиты баз данных, использование фаерволов, заточенных под базы данных, мониторинг активности и другие меры.
Эффективное управление жизненным циклом данных и устройств хранения, включающее в себя безопасное удаление информации (в том числе из облака), в которых нет необходимости. Принцип здесь довольно простой: злоумышленник не сможет скомпрометировать информацию, которой не существует. Кроме того, следует внедрять процедуры безопасной утилизации устаревших носителей.
Административные меры сводятся к трем «П» (Политика, Планирование, Процедуры), каждая из которых играет важную в контексте безопасности хранилищ данных. Если говорить конкретно, то, к примеру, политики безопасности должны определять места хранения для различных типов информации, разграничивать права доступа, типы шифрования и моменты, когда следует удалять ненужные данные.
Учитывать аспекты хранения в политиках безопасности после идентификации наиболее важных и критичных для бизнеса категорий информации и требований к защите.
Интегрирование политик, специфичных для хранилищ, и других регламентов там, где возможно.
Внедрение мер сохранности и защиты данных.
Внедрение мер по удалению информации и утилизации носителей.
Проверка на соответствие, что все элементы инфраструктуры хранения соответствуют политикам безопасности
В зависимости от отрасли и страны, где работает ваша организация, возможно потребуется соответствие одному или нескольким нормативно-правовым регламентам в сфере безопасности хранения информации, включая PCI-DSS, Sarbanes Oxley, HIPAA, GDPR и другим.
Наказание за несоответствие вышеуказанным стандартам и, как следствие, уязвимости в системе безопасности, могут быть суровыми – начиная от штрафов и заканчивая тюремным заключением. Однако в некоторых случаях использование специфических мер безопасности не предписывается.
Например, в стандарте GDPR упоминается шифрование, но использование не является обязательным. Однако в случае серьезного инцидента, последствия неиспользования шифрования могут быть очень серьезными и даже сделано заключение, что реализованных мер недостаточно для соответствия GDPR.
Другие регламенты являются более специфическими. Например, стандарт PCI-DSS предписывает шифрование владельца карты при передаче через публичные сети.
Главное, нужно помнить, что эти регламенты созданы с целью помочь в реализации эффективных мер безопасности. Соответствие регламентам не означает, что система безопасности компании работает эффективно, но очень редко меры, предпринятые для обеспечения соответствия, сделают систему безопасности организации менее эффективной, чем, если бы эти меры не были бы внедрены совсем.