SS
но желающие функционала были
Size: a a a
2018 May 10
SS
живые, реальные, ощутимые :D
SS
что конкретно они хранят я не знаю
SS
UPDATE very_secret_table SET badly_secret_field='XXX'
KO
пример не из головы, panы pci/dss требует шифровать
KO
только вот ваш tmpfs тоже шифрованный будет в pci/dss контуре
AK
тут надо вспомнить, что data at rest encryption для mysql был сначала разработан в google и передан в mariadb. что в общем намекает кому и когда это нужно -- облака. ну или в общем случае, когда есть разграничение между теми, кто эксплуатирует сервер и теми, кто его использует (приложения)
AM
@pdobryakov "ни одна платёжка и иже с ними с pci dss такого не допускает"
Да ладно? храни сколько хочешь. Да и возможно ты сам имеешь pci dss.
Да ладно? храни сколько хочешь. Да и возможно ты сам имеешь pci dss.
ПД
Не, подход понятен: «позволяем пользователю писать что угодно , и шифруем все сами» .
AK
а также "сами управляем ключами"
ПД
@pdobryakov "ни одна платёжка и иже с ними с pci dss такого не допускает"
Да ладно? храни сколько хочешь. Да и возможно ты сам имеешь pci dss.
Да ладно? храни сколько хочешь. Да и возможно ты сам имеешь pci dss.
Ну сам факт pci.. для примера был. Когда есть сама идея «а давайте номер карточки/любую секретную информацию/ в базе в открытом виде хранить» тут видимо проблема не в отсутствии шифрования tmpfs )
AM
любую информацию можно назвать секретной
AM
Всё шифровать программно?
ПД
Ну что секретно , что нет - решают,по идее, архитекторы конечного приложения , а не движок бд - не?)
SS
Вот именно. Движок просто шифрует всё подряд и всё, не разбирая секретное он зашифровал или нет
AK
код приложения может быть невозможно/трудно изменить. шифровать на стороне приложения можно, но проще (и иногда безопаснее) делать это централизованно. с данными, зашифрованными на клиенте, субд может работать только как с блобами, без индексов и прочей обработки на стороне сервера. как-то так
ПД
Про «удобно» да- само собой, но «полезно»-ли ?
AK
"зависит" :)
2018 May 11
ls
Всем доброго дня. Есть такой вопрос: можно ли в одной топологии репликации совместить классическую репликацию на основе позиций в журналах и gtid-репликацию, с условием, чтобы на оконечных слейвах использовалась автопозиция? Или попытки будут тщетны, и это технически не реализовать из-за разных протоколов репликации?