Data encryption at rest - WTF?

[Dmitry67]

У нас девы могут зайти на продакшн. По тикету, на лимитированное время, с логом операций, но могут

И аудиторы на это посмотрят нормально поскольку процесс судя по всему прописан и контролируем. Это скорее всего будет рассмотрено как exception process. Но обязательно проверят задокументирован ли и выполняется ли согласно документов, нет ли исключений.

Control environment создается на основании risk assessment и должен быть economically feasible. Все таки получение прибыли никто не отменял.

О да. Аудиторы очень придирчиво эти отчеты смотрели и делали выборочные проверки. Мне пришлось участвовать в процессе удовлетворения аудиторов)

[alex_127]

У нас девы могут зайти на продакшн. По тикету, на лимитированное время, с логом операций, но могут

И аудиторы на это посмотрят нормально поскольку процесс судя по всему прописан и контролируем. Это скорее всего будет рассмотрено как exception process. Но обязательно проверят задокументирован ли и выполняется ли согласно документов, нет ли исключений.

Control environment создается на основании risk assessment и должен быть economically feasible. Все таки получение прибыли никто не отменял.

О да. Аудиторы очень придирчиво эти отчеты смотрели и делали выборочные проверки. Мне пришлось участвовать в процессе удовлетворения аудиторов)

главное это тщательно отделять тех коgo аудиторам показывать можно от тех кто на самом деле может устроить проблему интернетного масштаба...

[Searcher]

главное это тщательно отделять тех коgo аудиторам показывать можно от тех кто на самом деле может устроить проблему интернетного масштаба...

Не принципиально. Слова не являются определяющими.

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

[StrangerR]

Итог дискуссии. Данная мера неэффективна сама по себе и ее можно обойти - согласен.

Посмотрим немного по-другому. Вопрос изначально поставлен в контексте "изолированного коня в вакууме". При таком рассмотрении эта мера действительно может выглядеть глупо. Однако никто не ограничивается data encryption at rest. Это один из controls в control environment организации.

Когда нанимают, делают background check. После этого дают подписать NDA, terms of use, и заставляют пройти infosec training, который надо проходить ежегодно (с электронной подписью в конце). Доступа в системы из которых можно получить доступ к данным дается только на основании need to know. Девелопер к production system не подпускается на пушечный выстрел. Административный пароль можно получить только по запросу, после management approval, и только с привязкой к change management ticket. То что там делается под администратором пишется в лог (в совершенно другое, недоступное место) и отслеживается посредством того же Splunk. Если Splunk триггер срабатывает, то подключается человек. Попытки отправить информацию за пределы корпоративной сети отслеживаются системой DLP. Возможность копирования на внешний носитель - отключена или приводит к звонку из infosec с вопросом "а что это вы там в USB порт воткнули?"
И так далее. Там еще много чего делается. NIST SP800-53.

Если организация хочет оказывать услуги в financial industry и этого нет, то выбор: или создавайте или не получите контракт.

На практике все это обходится очень быстро. Кроме разделения продакшена и всего остального, и то если все грамотно сделано (что редкость). ТО есть бумаг то пишется много, но насчет Сплунк триггера - обычно там идет тысяча в день и никто туда не смотрит уже лет 5, это то что мне попадалось... Ну а про USB вообще насмешили, уж передать то файл всегда можно, никакой DLP тут не поможет.

Аудиторы это конечно хорошо. Иногда, раз в сто лет, от них даже польза есть. Хотя после года работы польза резко упала а вот вред в виде _отвлечения от реальных дел_ начал расти. И я знаю кучу мест которые аудитор вообще не видит и не увидит и которые серьезнее того, куда он копает. К сожалению, аудитор он не бог и на деле на него надеяться лучше не стоит...

[mskmel]

Я данные просто из памяти базы данных считаю. Через dd /dev/mem my-file. Делов то. зачем мне эти ключи, они все одно уже введены и уже активированы.

Не всё так просто. Данные в БД хранятся шифрованные, не все но те что попадают под compliance. Вот https://www.voltage.com/products/data-s ... nterprise/ или еще https://www.ibm.com/security/data-security/guardium ну и еще один https://www.thalesesecurity.com/product ... encryption
Вы из памяти считаете... кусок зашифрованных данных. Админ приложений, считает тоже самое.
Любой запрос на дешифрацию логгируется, кто, откуда, когда и т.п.

[StrangerR]

ну так select * from table эти данные прекрасно расшифровывает. И они прекрасно сидят в памяти. Это если просто таблички шифровать.

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

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

[Flash-04]

Когда нанимают, делают background check. После этого дают подписать NDA, terms of use, и заставляют пройти infosec training, который надо проходить ежегодно (с электронной подписью в конце). Доступа в системы из которых можно получить доступ к данным дается только на основании need to know. Девелопер к production system не подпускается на пушечный выстрел. Административный пароль можно получить только по запросу, после management approval, и только с привязкой к change management ticket. То что там делается под администратором пишется в лог (в совершенно другое, недоступное место) и отслеживается посредством того же Splunk. Если Splunk триггер срабатывает, то подключается человек. Попытки отправить информацию за пределы корпоративной сети отслеживаются системой DLP. Возможность копирования на внешний носитель - отключена или приводит к звонку из infosec с вопросом "а что это вы там в USB порт воткнули?"
И так далее. Там еще много чего делается. NIST SP800-53.

наш человек

[StrangerR]

Когда нанимают, делают background check. После этого дают подписать NDA, terms of use, и заставляют пройти infosec training, который надо проходить ежегодно (с электронной подписью в конце). Доступа в системы из которых можно получить доступ к данным дается только на основании need to know. Девелопер к production system не подпускается на пушечный выстрел. Административный пароль можно получить только по запросу, после management approval, и только с привязкой к change management ticket. То что там делается под администратором пишется в лог (в совершенно другое, недоступное место) и отслеживается посредством того же Splunk. Если Splunk триггер срабатывает, то подключается человек. Попытки отправить информацию за пределы корпоративной сети отслеживаются системой DLP. Возможность копирования на внешний носитель - отключена или приводит к звонку из infosec с вопросом "а что это вы там в USB порт воткнули?"
И так далее. Там еще много чего делается. NIST SP800-53.

наш человек

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

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

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

[Flash-04]

StrangerR, я надеюсь не надо обьяснять что в нашей профессии нет "серебрянной пули"? вместо этого учат ставить стройные ряды спотыкачей, на одном из которых злоумышленник таки сделает неверный ход.

[Flash-04]

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

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

[mskmel]

ну так select * from table эти данные прекрасно расшифровывает. И они прекрасно сидят в памяти. Это если просто таблички шифровать.

Сходите по линкам, почитайте... Все эти стандарты и инструменты разрабатывают совсем не глупые люди.
select * from table вернёт Вам зашифрованный колонки.

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

Для этого не нужны SPI, PCI, HIPAA и т.п. данные. In motion\use шифруется не всё, а только то, что попадает под compliance. Согласен часто это редкостный геморрой, но таковы правила игры.

Но пока это обеспечить практически никто не может.

Задача максимально усложнить получение важных данных и иметь максимальный контроль над доступом. Считается, что "вынести" можно всё.

[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]