Green-sell.info

Новые технологии
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Безопасное хранение база данных

Безопасное хранение паролей

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

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

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

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

3. В ряде случаев такая схема работы доставляет объективные неудобства или принципиально невозможна:

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

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

3.1. При этом не следует хранить пароли и другую конфиденциальную информацию в реквизитах тех же объектов метаданных, с которыми ведется повседневная работа. Для хранения такой информации следует использовать отдельный объект метаданных (например, регистр сведений), организовав к нему безопасный доступ на уровне системы прав доступа 1С:Предприятия.

3.2. При использовании Библиотеки стандартных подсистем (БСП) следует использовать безопасное хранилище паролей, которое решает ряд задач:

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

Для работы с безопасным хранилищем паролей предназначены процедуры и функции общего модуля ОбщегоНазначения: ЗаписатьДанныеВБезопасноеХранилище, ПрочитатьДанныеИзБезопасногоХранилища и УдалитьДанныеИзБезопасногоХранилища. Подробнее см. комментарии к этим функциям в БСП и раздел «3.4. Базовая функциональность — Использование при разработке конфигурации — Безопасное хранилище паролей» документации БСП.

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

Для маскировки пароля на форме в обработчике событии формы ПриСозданииНаСервере необходимо разместить следующий код:

УстановитьПривилегированныйРежим(Истина);
Пароли = ОбщегоНазначения.ПрочитатьДанныеИзБезопасногоХранилища(Объект.Ссылка, «Пароль, ПарольSMTP»); // Пароль, ПарольSMTP – ключи соответствия данных в безопасном хранилище
УстановитьПривилегированныйРежим(Ложь);

Пароль = ?(ЗначениеЗаполнено(Пароли.Пароль), ЭтотОбъект.УникальныйИдентификатор, «»);
ПарольSMTP = ?(ЗначениеЗаполнено(Пароли.ПарольSMTP), ЭтотОбъект.УникальныйИдентификатор, «»);

В обработчике события формы ПриЗаписиНаСервере:

Если ПарольИзменен Тогда
УстановитьПривилегированныйРежим(Истина);
ОбщегоНазначения.ЗаписатьДанныеВБезопасноеХранилище(ТекущийОбъект.Ссылка, Пароль);
УстановитьПривилегированныйРежим(Ложь);
Пароль = ?(ЗначениеЗаполнено(Пароль), ЭтотОбъект.УникальныйИдентификатор, «»);
КонецЕсли;

Если ПарольSMTPИзменен Тогда
УстановитьПривилегированныйРежим(Истина);
ОбщегоНазначения.ЗаписатьДанныеВБезопасноеХранилище(ТекущийОбъект.Ссылка, ПарольSMTP, «ПарольSMTP»);
УстановитьПривилегированныйРежим(Ложь);
ПарольSMTP = ?(ЗначениеЗаполнено(ПарольSMTP), ЭтотОбъект.УникальныйИдентификатор, «»);
КонецЕсли;

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

Основные аспекты безопасности СУБД: что следует знать

    Статьи, 25 ноября 2016 в 19:35

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

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

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

История развития СУБД

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

Можно выделить следующие архитектурные подходы:

  • полный доступ всех пользователей к серверу БД;
  • разделение пользователей на доверенных и частично доверенных средствами СУБД;
  • введение системы аудита (логов действий пользователей) средствами СУБД;
  • введение шифрования данных; вынос средств аутентификации за пределы СУБД в операционные системы и промежуточное ПО; отказ от полностью доверенного администратора данных.

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

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

Современные проблемы обеспечения безопасности БД

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

  • проблемами безопасности серьезно занимаются только крупные производители;
  • программисты баз данных, прикладные программисты и администраторы не уделяют должного внимания вопросам безопасности;
  • разные масштабы и виды хранимых данных требуют разных подходов к безопасности;
  • различные СУБД используют разные языковые конструкции для доступа к данным, организованным на основе одной и той же модели;
  • появляются новые виды и модели хранения данных.

Многие уязвимости сохраняют актуальность за счет невнимания или незнания администраторами систем баз данных вопросов безопасности. Например, простые SQL-инъек­ции широко эксплуатируются сегодня в отношении различных web-приложений, в которых не уделяется достаточного внимания входным данным запросов.

Применение различных средств обеспечения информационной безо­пасности является для организации компромиссом в финансовом плане: внедрение более защищенных продуктов и подбор более квалифицированного персонала требуют больших затрат. Компоненты безопасности зачастую могут негативно влиять на производительность СУБД.

Эти проблемы усугубляются с появлением и широким распространением нереляционных СУБД, оперирующих другой моделью данных, однако построенных по тем же принципам, что и реляционные. Многообразие современных NoSQL-решений приводит к разнообразию применяемых моделей данных и размывает границу понятия БД.

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

Особенности защиты БД

Хранилища данных включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).

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

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

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

Архитектура применяемых языков, по крайней мере, то, что касается специализированных языков и наборов функций, напрямую связана с моделью данных, применяемой для хранения информации. Таким образом, модель определяет особенности языка, и наличие в нем тех или иных уязвимостей. Причем такие уязвимости, например, как инъекция, выполняются по-разному (sql-инъекция, java-инъек­ция) в зависимости от синтаксиса языка.

Требования к безопасности БД

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

Не зависящими от данных мож­но назвать следующие требования к безопасной системе БД:

  • Функционирование в доверенной среде.

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

  • Организация физической безопасности файлов данных.

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

  • Организация безопасной и актуальной настройки СУБД.

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

Следующие требования можно назвать зависящими от данных:

  • Безопасность пользовательского ПО.

Сюда можно отнести задачи построения безопасных интерфейсов и механизмов доступа к данным.

  • Безопасная организация и работа с данными.

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

Основные аспекты создания защищенных БД

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

  • Разработка комплексных методик обеспечения безопасности хранилищ данных на предприятии.

Создание комплексных методик позволит применять их при разработке и внедрении хранилищ данных и пользовательского ПО. Следование комплексной методике позволит избежать многих ошибок управления СУБД и защититься от наиболее распространенных на сегодняшний день уязвимостей.

  • Оценка и классификация угроз и уязвимостей СУБД.

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

  • Разработка стандартных механизмов обеспечения безопасности.

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

Об авторе

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

Лучшие практики по безопасности хранилищ данных

В статье рассматриваются ключевые угрозы, связанные с информационными хранилищами

Автор: Paul Rubens

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

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

Хорошо спроектированная система безопасности также предусматривает соответствие разным нормативным положениями, как, например, 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 предписывает шифрование владельца карты при передаче через публичные сети.

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

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

Безопасное хранение конфиденциальных данных в базе данных

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

В принципе, у меня есть таблица patient , в которой хранится публичная (= несекретная) информация о пациентах. Некоторые другие сведения (например, имя, адрес) являются частными и должны быть надежно сохранены. Я использую пару открытых / закрытых ключей, сгенерированную PHP OpenSSL и отправленную менеджером веб-сайта. Парольная фраза известна только людям, которым разрешен доступ к личным данным (в основном, поставщикам медицинских услуг). Я хотел бы хранить их в другой таблице. Первый вопрос, является ли BLOB лучшим типом столбца (с MySQL) для хранения двоичных данных. Или я должен преобразовать их (например, с base64 ) и сохранить их в столбце VARCHAR ?

Моя таблица patient_secure_data выглядит так:

Это таблица ключ-значение, где значение запечатано openssl_seal . Мне нужно сохранить третий параметр ( $env_keys ), чтобы иметь возможность расшифровывать данные. Итак, второй вопрос: зачем мне нужен этот env_keys , если у меня есть пароль закрытого ключа, когда я вызываю openssl_open ?

Третий (и последний) вопрос: это безопасная схема базы данных? Я имею в виду, могу ли я гарантировать, что никто без пароля не сможет увидеть личные данные?

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

Извините, если мой язык не идеален, я не являюсь носителем английского языка. Надеюсь, я ясно выразился.

2 Ответа

1-BLOB является моим предпочтением, потому что кодирование его в base64 увеличит как пространство, так и время обработки (так как вам придется также декодировать base64 перед расшифровкой)

2 — openssl_seal не дает вам ключ, который был использован для шифрования данных. Назначение env_keys-хранить зашифрованную форму сгенерированного ключа. Когда вы вызываете openssl_open, вы даете ему этот ключ конверта и закрытый ключ, который он должен расшифровать ключ конверта. Закрытый ключ должен быть сопоставлен с открытым ключом, который использовался для создания ключа конверта.

3-Если ваш закрытый ключ требует парольной фразы, то технически ваши данные относительно безопасны. Даже если у них есть ключ от конверта и секретный ключ, они не смогут его использовать . но насколько надежна ваша парольная фраза? Следует понимать, что вы почти никогда не можете гарантировать полностью безопасную схему, но вы определенно можете сделать ее жесткой для хакеров. Используйте здесь свое воображение. Кстати, есть ли ваша парольная фраза в открытом тексте в вашем коде?

Все, что превышает 500chars, вероятно, должно быть blob (или clob).

Что касается ключей, вы должны хранить только открытый ключ в вашем public DB. Таким образом, вам не придется беспокоиться о том, что кто-то (пароль или нет) сможет расшифровать данные. Закрытая часть ключа должна храниться в чувствительном DB. Вам нужна только публичная часть, чтобы расшифровать данные, зашифрованные частной частью. Я бы не стал хранить весь ключ (public+private) на диске сервера, содержащем несекретную информацию, поскольку это ставит под угрозу безопасность ключа.

Похожие вопросы:

У меня есть следующее На месте для моего сайта PHP: SSL включено Cookies : session_set_cookie_params($cookieParams[lifetime], $cookieParams[path], $cookieParams[domain], $secure, $httponly); Пароли.

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

Возможный Дубликат : Какую функцию использовать для hash паролей в MySQL? Безопасное хранение паролей Каков наилучший механизм хранения паролей в базе данных после шифрования пароля? А что такое.

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

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

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

Я работаю над приложением Winforms в C#, которое должно будет получить доступ к сотруднику SSNs. Мы храним данные в базе данных сервера SQL. Очевидно, что мы не можем хранить числа в открытом тексте.

Как я могу хранить секретный ключ в устройстве android с единственной возможностью использовать ключ, а не извлекать его. Например: я импортирую частную / генерирую пару ключей RSA или симметричный.

Говоря конфиденциальные данные я имею в виду: Сертификаты Passwors другие личные секреты Вопрос 1 . Есть ли способ для сторонних приложений получить доступ к этой информации, хранящейся с помощью.

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

Безопасное хранение данных

Безопасное хранение данных

Безопасное хранение данных

Алексей Задонский, ведущий менеджер проектов в государственных структурах, компания Oracle

Характеристики хранилищ данных

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

Укажем лишь на основные черты, характеризующие такие системы:

  • весь основной объем информации накапливается в структурированных реляционных базах данных;
  • все компьютерные ресурсы обычно находятся в выделенных, хорошо охраняемых серверных комнатах (так называемые центры обработки данных);
  • хранилища — это не просто мертвый склад информации, но и наличие большого числа тесно связанных с ним прикладных и обслуживающих систем. Например, ПО для архивирования информации, управления, системы обработки типа ETL (extraction, transformation, loading), прикладные системы, которые, собственно, и порождают исходные данные, и т.д.;
  • средний размер хранилища составляет 1 Тбайт и выше, что диктует серьезное отношение к сетевой инфраструктуре и системам хранения и обработки информации.

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

Рассмотрим пример построения системы защиты типичного хранилища данных на основных уровнях.

Ясно, что территория хранилища должна быть максимально закрыта от попыток проникновения снаружи, поэтому при необходимости удаленного доступа обязательно шифрование трафика. И даже внутренняя сеть управления (которую желательно выделить отдельно с помощью VLAN или даже на физическом уровне, то есть управлять серверами по отдельным сетевым интерфейсам) должна шифроваться (SSH, IPSec, SSL и т.д.). Обязательно шифрование данных, выходящих наружу с использованием контроля целостности (MD5, SHA1). Обычно из-за больших объемов обрабатываемой информации не используют шифрование на уровне ядра сети из-за проблем с производительностью.

Разные сетевые протоколы и сетевые взаимодействия требуют наличия средств защиты на своем уровне.

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

  • организация VLAN, Port Security и т.д.;
  • proxy-серверы на периметре, анализирующие прикладной уровень взаимодействия;
  • системы предотвращения вторжений (IDS/IPS) и др.;
  • антивирусная защита и т.д.

Уровень Fibre Channel также требует своей защиты, например Fibre Channel Authentication Protocol, Switch Link Authentication Protocol и т.д.

На уровне Storage Area Networking применяется Virtual SAN, маркировка LUN и др.

Операционные и прикладные системы

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

Аутентификация и контроль доступа

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

Необходимы прикладные средства и организационные меры по распределению прав администраторов (баз данных, прикладных и операционных систем) и специалистов по информационной безопасности.

Принцип неотвратимости наказания в большинстве случаев является наиболее действенным методом обеспечения безопасности. Поэтому как минимум необходим многоуровневый аудит (независимый от администраторов) того, что происходит на всех уровнях. Здесь есть решения на разных уровнях. Для аудита того, что происходит в телекоммуникациях, прикладных и операционных системах можно использовать, например, решения ArcSight, NetForensics (чаще продающиеся под маркой корпорации Cisco Systems), CA Security Command Center. Но вдобавок к этому потребуется отдельный глубокий аудит того, что происходит на уровне баз данных, а это можно решить дополнительными средствами.

Защита баз данных

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

Разграничение доступа к базам данных

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

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

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

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

Читать еще:  Проверка безопасности google
Ссылка на основную публикацию
Adblock
detector