наш человек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.
Data encryption at rest - WTF?
-
- Уже с Приветом
- Posts: 63430
- Joined: 03 Nov 2004 05:31
- Location: RU -> Toronto, ON
Re: Data encryption at rest - WTF?
Not everyone believes what I believe but my beliefs do not require them to.
-
- Уже с Приветом
- Posts: 38016
- Joined: 14 Dec 2006 20:13
- Location: USA
Re: Data encryption at rest - WTF?
Ага, я с этими аудиторами уже месяца 4 как время трачу. Даже я бы сказал второй год. Проблема - если вначала это все приносило кучу улучшений, то в последнее время они исчерпали фантазии и привязываются к столбам при том что рядом известные мне калитки еще живут (ну не калитки но то что давно пора менять нафиг).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.
тут надо понимать что все это _опытки отправить информацию за пределы корпоративной сети отслеживаются системой DLP_ защищает только от случайной утечки. Если кто то захочет информацию отправить, то прекрасно отправит, отключай там запись на USB не отключай...
Да, а на фига девелоперам доступ к продакшен системе _по тикету_? Их туда вообще пускать нельзя. На чтение еще туда сюда да и то лучше на копию пустить. А так - изменение это скрипт (с номером тикета) которые опсы прогонят на копии а потом в заданное время в продакшене. А иначе.. что там кто понаделает, никакими аудитами не разберешься...
-
- Уже с Приветом
- Posts: 63430
- Joined: 03 Nov 2004 05:31
- Location: RU -> Toronto, ON
Re: Data encryption at rest - WTF?
StrangerR, я надеюсь не надо обьяснять что в нашей профессии нет "серебрянной пули"? вместо этого учат ставить стройные ряды спотыкачей, на одном из которых злоумышленник таки сделает неверный ход.
Not everyone believes what I believe but my beliefs do not require them to.
-
- Уже с Приветом
- Posts: 63430
- Joined: 03 Nov 2004 05:31
- Location: RU -> Toronto, ON
Re: Data encryption at rest - WTF?
в теории так и есть. на практике же нередко админ открывал консоль и давал мне remote control чтобы я уже всё делал. но это конечно скорее из-за лени.StrangerR wrote: ↑27 Jan 2018 05:44 Да, а на фига девелоперам доступ к продакшен системе _по тикету_? Их туда вообще пускать нельзя. На чтение еще туда сюда да и то лучше на копию пустить. А так - изменение это скрипт (с номером тикета) которые опсы прогонят на копии а потом в заданное время в продакшене. А иначе.. что там кто понаделает, никакими аудитами не разберешься...
Опять же в реальности бывает так что 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.
-
- Уже с Приветом
- Posts: 946
- Joined: 24 Sep 2013 05:58
- Location: US\GA
Re: Data encryption at rest - WTF?
Сходите по линкам, почитайте... Все эти стандарты и инструменты разрабатывают совсем не глупые люди.
select * from table вернёт Вам зашифрованный колонки.
Для этого не нужны SPI, PCI, HIPAA и т.п. данные. In motion\use шифруется не всё, а только то, что попадает под compliance. Согласен часто это редкостный геморрой, но таковы правила игры.
Задача максимально усложнить получение важных данных и иметь максимальный контроль над доступом. Считается, что "вынести" можно всё.
-
- Уже с Приветом
- Posts: 38016
- Joined: 14 Dec 2006 20:13
- Location: USA
Re: Data encryption at rest - WTF?
На практике должны быть DEV, STAGING и PROD, и последние две должны точно соответствовать друг другу.Flash-04 wrote: ↑27 Jan 2018 06:05в теории так и есть. на практике же нередко админ открывал консоль и давал мне remote control чтобы я уже всё делал. но это конечно скорее из-за лени.StrangerR wrote: ↑27 Jan 2018 05:44 Да, а на фига девелоперам доступ к продакшен системе _по тикету_? Их туда вообще пускать нельзя. На чтение еще туда сюда да и то лучше на копию пустить. А так - изменение это скрипт (с номером тикета) которые опсы прогонят на копии а потом в заданное время в продакшене. А иначе.. что там кто понаделает, никакими аудитами не разберешься...
Опять же в реальности бывает так что DEV & PROD таки не равны друг другу, и то что сработало на DEV не идёт 1-в-1 на PROD. тогда админ теряется, и тогда либо приходится говорить "а попробуй так", "а посмотри в другом фолдере", в общем моя практика траблшутинга довольно богата, и в ней были случаи когда в итоге консоль приходилось передавать в руки поддержки вендора, чтобы разобраться какого фига приложение на PROD выкаблучивается. Ну или можно стать в позу и жить дальше с "упавшей" системой.
Опять же из практики у меня был случай когда через несколько дней после апгрейда приложение "упало" в усмерть и поддержка вендора несколько дней ничего мне не отвечала (я так понял они сами не знали что сделать). В итоге практически по наитию я сам её поднял. Особая пикантность заключалась в том, что как-то подрались разные апдейты Oracle, и мне с помощью какой-то матери удалось этот конфликт разрешить (я не Oracle DBA ни разу). Как легко догадаться, никакого документа который я мог бы дать админу на исполнение, просто не было в природе. Но да, это было ещё время когда у меня был root на сервере. Сейчас бы такой фокус не удался бы. Думаю пришлось бы вызывать на сайт человека от вендора, сажать его вместе с алмином, и заняло это бы времени больше и стоило бы $$$$.
-
- Уже с Приветом
- Posts: 28294
- Joined: 29 Aug 2000 09:01
- Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Re: Data encryption at rest - WTF?
Или даже DEV, QA, UAT, PROD
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
-
- Уже с Приветом
- Posts: 28294
- Joined: 29 Aug 2000 09:01
- Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Re: Data encryption at rest - WTF?
Вы оба правы
Есть 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
-
- Уже с Приветом
- Posts: 63430
- Joined: 03 Nov 2004 05:31
- Location: RU -> Toronto, ON
Re: Data encryption at rest - WTF?
Для business critical applications - да. Для остальных как получится. Да, бардак
Not everyone believes what I believe but my beliefs do not require them to.
-
- Уже с Приветом
- Posts: 38016
- Joined: 14 Dec 2006 20:13
- Location: USA
Re: Data encryption at rest - WTF?
У нас аналогично...