А как шифровать данные?

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

В запароленных архивах или шифрованных контейнерах (типа TrueCrypt).

По ГОСТу принято😊 Сигнатура, Верба, и тп.

Плюс анально огороженный криптосервер Янтарь, например.

При чём тут соль вообще, не понял. Соль это против перебора хешей паролей через таблицы.

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

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

Что должен делать демон?

Да вопрос непонятно о чем: шифрование передаваемых данных, хранимых в БД данных предметной области, выгруженных для долгосрочного хранения в архивах данных-артефактов, данных аутентификации, о каких данных вообще идёт речь? И шифрование на каком уровне - на уровне транспортной подсистемы, лвс, прикладном, уровня файловой системы, субд?

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

В смысле, для одного программного комплекса.

Нас взломали, вытащили данные, вытащили соль и расшифровали.

соль есть а пароля нет, вы случайно не наркоманы?

Обычный криптосервер?

Как в супер секьюрном ынтырпрайзе принято шифровать данные?

даже в самых колхозных ПТУ программистам рассказывают что безопасность это комплекс мер, а не тупо я «что-то криптонул»

просто потому что если у какиря есть доступ к машине то он может сделать дамп памяти твоего процесса и вытянуть оттуда и пароль и расшифрованные данные

и что мешает какрию попросить криптосервер расшифровать?

Программистам рассказывают что-то полезное в учебном заведении? Утопия.

Давайте, чтоб я не гадал, вы скажете - предполагается что хакер получил доступ к каким объектам?

А если в общем - то см. мой комментарий выше про средства защиты информации.

вы случайно не наркоманы?

Я — немножко, но ситуация выдумана :)

хранимых в БД данных предметной области

this

Соль это против перебора хешей паролей через таблицы.

Понял. Тогда поставлю вопрос иначе. Допустим, есть сервер, который перед тем как записать данные в базу шифрует их, а перед тем как достать — расшифровывает. У него есть ключ, которым он пользуется для шифрования/расшифровывания. Как хранить этот ключ, если учесть, что сервер опенсорсный и способы получения этого ключа легко прочесть в исходниках, даже если там будет что-то нетривиальное?

Встроенными в СУБД средствами, на уровне всей базы данных (тут нужно сделать важное замечание про ГОСТ). Файлы базы данных на уровне файловой системы средствами СЗИ от НСД.

С ГОСТ есть трудности при шифровании на уровне базы данных и на уровне MQ-шки, насколько я знаю.

Есть способы средствами СУБД шифровать данные более утонченно - не на уровне БД целиком, а на уровне таблиц/столбцов, но практического применения не встречал.

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

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

Мой вопрос заключается в том же.

Стоп. Давайте по порядку - доступ к чему именно получил хакер?

Он соединился с сервером БД с непривилегированной учётной записью? Он получил доступ к файлам прикладных БД но не соединился с сервером? Он получил доступ к файлам системных БД но не соединился с сервером? Он вытащил жёсткие диски из сервера? Он получил привилегированную учетную запись сервера БД и подключился к нему ? Он получил доступ к АРМ и работает от имени легитимного пользователя?

На каком уровне он получил доступ?

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

Что должен делать демон?

Шифровать, хешировать, смотря что надо. Например реализовывать функцию f(password, public_hash) -> hash(public_hash + private_hash + password) для хеширования, не позволяя раскрыть пароли по стыренной БД (можно перебирать, пока не раскрыли факт взлома и не закрыли лазейки).

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

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

Но почему именно демон?

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

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

Понял.

Как хранить этот ключ, если учесть, что сервер опенсорсный и способы получения этого ключа легко прочесть в исходниках, даже если там будет что-то нетривиальное?

В ынтерпрайзе - только так: https://www.thales-esecurity.com/products-and-services/products-and-services/...

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

Про хранение ключа для шифрования базы данных (на примере субд-империи-зла): все такие ключи сводятся к единственному мастер ключу - доступ к нему нужен только один раз, при запуске сервиса базы данных и от имени пользователя, из под которого работает сервис. Он не хранится в открытом виде нигде. Вводишь пароль при запуске сервиса - ключ видимо расшифровывается. Это все делается на уровне ОС, а не прикладухи.

Если такое же склепать нужно в прикладухе, я бы сделал по образу и подобию.

Или сертифицированная от Крипто-ПРО.

Понял, спасибо за рекомендации.

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

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

Я тут не имею ввиду средства разграничения доступа в самой прикладухе - оно понятное дело закладывается сразу.

Ещё риски бывают реальными и мифическими. Кто реальную угрозу представляет - кульхацкеры или персонал?

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

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