Data encryption at rest - WTF?

[StrangerR]

Да, а на фига девелоперам доступ к продакшен системе _по тикету_? Их туда вообще пускать нельзя. На чтение еще туда сюда да и то лучше на копию пустить. А так - изменение это скрипт (с номером тикета) которые опсы прогонят на копии а потом в заданное время в продакшене. А иначе.. что там кто понаделает, никакими аудитами не разберешься...

в теории так и есть. на практике же нередко админ открывал консоль и давал мне remote control чтобы я уже всё делал. но это конечно скорее из-за лени.
Опять же в реальности бывает так что DEV & PROD таки не равны друг другу, и то что сработало на DEV не идёт 1-в-1 на PROD. тогда админ теряется, и тогда либо приходится говорить "а попробуй так", "а посмотри в другом фолдере", в общем моя практика траблшутинга довольно богата, и в ней были случаи когда в итоге консоль приходилось передавать в руки поддержки вендора, чтобы разобраться какого фига приложение на PROD выкаблучивается. Ну или можно стать в позу и жить дальше с "упавшей" системой.
Опять же из практики у меня был случай когда через несколько дней после апгрейда приложение "упало" в усмерть и поддержка вендора несколько дней ничего мне не отвечала (я так понял они сами не знали что сделать). В итоге практически по наитию я сам её поднял. Особая пикантность заключалась в том, что как-то подрались разные апдейты Oracle, и мне с помощью какой-то матери удалось этот конфликт разрешить (я не Oracle DBA ни разу). Как легко догадаться, никакого документа который я мог бы дать админу на исполнение, просто не было в природе. Но да, это было ещё время когда у меня был root на сервере. Сейчас бы такой фокус не удался бы. Думаю пришлось бы вызывать на сайт человека от вендора, сажать его вместе с алмином, и заняло это бы времени больше и стоило бы $$$$.

На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.

[Dmitry67]

На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.

Или даже DEV, QA, UAT, PROD

[Dmitry67]

select * from table вернёт Вам зашифрованный колонки.

Вы оба правы
Есть transparent low level encryption на sql server файлах, тогда select * возвращает все в читаемом виде
Можно шифровать колонки, это другое. Тогда DBA их тоже не увидит, но на практике это решение малоприменимо. Вы можете, например, зашифровать поле SSN, но тогда искать можете только как WHERE decrypt(SSN...)='010xxxyyyyy' с полным table scan и расшифровкой каждой записи. Изза salting решение SSN=enrypt('SSN который я ищу') работать не будет ). Поэтому это решение практчески не применяется и DBA по прежнему всемогущи

P.S.
Интеренсно что transparent low level encryption может делать как сам MS SQL, так и например storage (NetApp). Мне интересно, победит ли в конце концов параноя и включат ли шифрование и там и там

P.P.S
Кстати, шифрование at rest выше уровня storage полностью убивает deduplication на уровне storage...

[Flash-04]

На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.

Или даже DEV, QA, UAT, PROD

Для business critical applications - да. Для остальных как получится. Да, бардак [emoji38]

[StrangerR]

На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.

Или даже DEV, QA, UAT, PROD

Для business critical applications - да. Для остальных как получится. Да, бардак [emoji38]

У нас аналогично...