Data encryption at rest - WTF?

User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Data encryption at rest - WTF?

Post by Flash-04 »

Searcher wrote: 26 Jan 2018 16:33 Когда нанимают, делают 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.
наш человек :fr:
Not everyone believes what I believe but my beliefs do not require them to.
StrangerR
Уже с Приветом
Posts: 38046
Joined: 14 Dec 2006 20:13
Location: USA

Re: Data encryption at rest - WTF?

Post by StrangerR »

Flash-04 wrote: 27 Jan 2018 05:39
Searcher wrote: 26 Jan 2018 16:33 Когда нанимают, делают 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.
наш человек :fr:
Ага, я с этими аудиторами уже месяца 4 как время трачу. Даже я бы сказал второй год. Проблема - если вначала это все приносило кучу улучшений, то в последнее время они исчерпали фантазии и привязываются к столбам при том что рядом известные мне калитки еще живут (ну не калитки но то что давно пора менять нафиг).

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

Да, а на фига девелоперам доступ к продакшен системе _по тикету_? Их туда вообще пускать нельзя. На чтение еще туда сюда да и то лучше на копию пустить. А так - изменение это скрипт (с номером тикета) которые опсы прогонят на копии а потом в заданное время в продакшене. А иначе.. что там кто понаделает, никакими аудитами не разберешься...
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Data encryption at rest - WTF?

Post by Flash-04 »

StrangerR, я надеюсь не надо обьяснять что в нашей профессии нет "серебрянной пули"? вместо этого учат ставить стройные ряды спотыкачей, на одном из которых злоумышленник таки сделает неверный ход.
Not everyone believes what I believe but my beliefs do not require them to.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Data encryption at rest - WTF?

Post by Flash-04 »

StrangerR wrote: 27 Jan 2018 05:44 Да, а на фига девелоперам доступ к продакшен системе _по тикету_? Их туда вообще пускать нельзя. На чтение еще туда сюда да и то лучше на копию пустить. А так - изменение это скрипт (с номером тикета) которые опсы прогонят на копии а потом в заданное время в продакшене. А иначе.. что там кто понаделает, никакими аудитами не разберешься...
в теории так и есть. на практике же нередко админ открывал консоль и давал мне remote control чтобы я уже всё делал. но это конечно скорее из-за лени.
Опять же в реальности бывает так что DEV & PROD таки не равны друг другу, и то что сработало на DEV не идёт 1-в-1 на PROD. тогда админ теряется, и тогда либо приходится говорить "а попробуй так", "а посмотри в другом фолдере", в общем моя практика траблшутинга довольно богата, и в ней были случаи когда в итоге консоль приходилось передавать в руки поддержки вендора, чтобы разобраться какого фига приложение на PROD выкаблучивается. Ну или можно стать в позу и жить дальше с "упавшей" системой.
Опять же из практики у меня был случай когда через несколько дней после апгрейда приложение "упало" в усмерть и поддержка вендора несколько дней ничего мне не отвечала (я так понял они сами не знали что сделать). В итоге практически по наитию я сам её поднял. Особая пикантность заключалась в том, что как-то подрались разные апдейты Oracle, и мне с помощью какой-то матери удалось этот конфликт разрешить (я не Oracle DBA ни разу). Как легко догадаться, никакого документа который я мог бы дать админу на исполнение, просто не было в природе. Но да, это было ещё время когда у меня был root на сервере. Сейчас бы такой фокус не удался бы. Думаю пришлось бы вызывать на сайт человека от вендора, сажать его вместе с алмином, и заняло это бы времени больше и стоило бы $$$$.
Not everyone believes what I believe but my beliefs do not require them to.
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: Data encryption at rest - WTF?

Post by mskmel »

StrangerR wrote: 27 Jan 2018 05:11 ну так select * from table эти данные прекрасно расшифровывает. И они прекрасно сидят в памяти. Это если просто таблички шифровать.
Сходите по линкам, почитайте... Все эти стандарты и инструменты разрабатывают совсем не глупые люди.
select * from table вернёт Вам зашифрованный колонки.
StrangerR wrote: 27 Jan 2018 05:11Но тут вылезает необходимость печатать инвойсы, делать репорты и прочее, и для них все равно делается массовая расшифровка данных
Для этого не нужны SPI, PCI, HIPAA и т.п. данные. In motion\use шифруется не всё, а только то, что попадает под compliance. Согласен часто это редкостный геморрой, но таковы правила игры.
StrangerR wrote: 27 Jan 2018 05:11Но пока это обеспечить практически никто не может.
Задача максимально усложнить получение важных данных и иметь максимальный контроль над доступом. Считается, что "вынести" можно всё.
StrangerR
Уже с Приветом
Posts: 38046
Joined: 14 Dec 2006 20:13
Location: USA

Re: Data encryption at rest - WTF?

Post by StrangerR »

Flash-04 wrote: 27 Jan 2018 06:05
StrangerR wrote: 27 Jan 2018 05:44 Да, а на фига девелоперам доступ к продакшен системе _по тикету_? Их туда вообще пускать нельзя. На чтение еще туда сюда да и то лучше на копию пустить. А так - изменение это скрипт (с номером тикета) которые опсы прогонят на копии а потом в заданное время в продакшене. А иначе.. что там кто понаделает, никакими аудитами не разберешься...
в теории так и есть. на практике же нередко админ открывал консоль и давал мне remote control чтобы я уже всё делал. но это конечно скорее из-за лени.
Опять же в реальности бывает так что DEV & PROD таки не равны друг другу, и то что сработало на DEV не идёт 1-в-1 на PROD. тогда админ теряется, и тогда либо приходится говорить "а попробуй так", "а посмотри в другом фолдере", в общем моя практика траблшутинга довольно богата, и в ней были случаи когда в итоге консоль приходилось передавать в руки поддержки вендора, чтобы разобраться какого фига приложение на PROD выкаблучивается. Ну или можно стать в позу и жить дальше с "упавшей" системой.
Опять же из практики у меня был случай когда через несколько дней после апгрейда приложение "упало" в усмерть и поддержка вендора несколько дней ничего мне не отвечала (я так понял они сами не знали что сделать). В итоге практически по наитию я сам её поднял. Особая пикантность заключалась в том, что как-то подрались разные апдейты Oracle, и мне с помощью какой-то матери удалось этот конфликт разрешить (я не Oracle DBA ни разу). Как легко догадаться, никакого документа который я мог бы дать админу на исполнение, просто не было в природе. Но да, это было ещё время когда у меня был root на сервере. Сейчас бы такой фокус не удался бы. Думаю пришлось бы вызывать на сайт человека от вендора, сажать его вместе с алмином, и заняло это бы времени больше и стоило бы $$$$.
На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Re: Data encryption at rest - WTF?

Post by Dmitry67 »

StrangerR wrote: 27 Jan 2018 11:05 На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.
Или даже DEV, QA, UAT, PROD
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Re: Data encryption at rest - WTF?

Post by Dmitry67 »

mskmel wrote: 27 Jan 2018 06:25 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...
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Data encryption at rest - WTF?

Post by Flash-04 »

Dmitry67 wrote:
StrangerR wrote: 27 Jan 2018 11:05 На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.
Или даже DEV, QA, UAT, PROD
Для business critical applications - да. Для остальных как получится. Да, бардак Image
Not everyone believes what I believe but my beliefs do not require them to.
StrangerR
Уже с Приветом
Posts: 38046
Joined: 14 Dec 2006 20:13
Location: USA

Re: Data encryption at rest - WTF?

Post by StrangerR »

Flash-04 wrote: 27 Jan 2018 13:07
Dmitry67 wrote:
StrangerR wrote: 27 Jan 2018 11:05 На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.
Или даже DEV, QA, UAT, PROD
Для business critical applications - да. Для остальных как получится. Да, бардак Image
У нас аналогично...

Return to “Вопросы и новости IT”