![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Слон в комнате
Mar. 6th, 2019 02:08 pmТ.к. щас эпоха облаков и все в них переезжают, все спрашивают а как там чо с безопасностью? По сравнению, разумеется, со своей серверной или коло.
Здесь есть несколько переплетающихся трендов и конкретный ответ для конкретного тенанта будет разным.
Ну, например, патчинг в облаках, при прочих равных, будет лучше, чем он-премисес. Разумеется, возможны исключения, но хорошая и работающая патчинг программа в крупном энтерпрайзе стоит больших денег, как по софту, так и по людям, а главное, по культуре -- попробуй владельцу бизнес направления, который приносит фирме деньги, втолкуй, что отныне и навсегда его серверы будут перезагружаться минимум раз в месяц, а при out-of-band (т.е. в критических ситуациях, которые случаются неск. раз в год) так и вообще в произвольное время, будучи членом ИТ-направления, которое никаких денег не приносит ваще и только одни бесконечные расходы. Т.е. проблема патчинга в облаках не столько техническая, сколько психологическая, как и почти всё в ИТ. Человеческая природа, ебана.
Другой тренд это т.н. ubiquity, который есть часть определения облачных сервисов. Тоись, доступность отовсюду. А оно вам надо, чтобы кокойты хуй из Уганды или Нигерии или из России подбирал пароли к вашим аккаунтам? Чуть усложнив, через американский прокси? Разумеется, это никому не надо. Поэтому предлагается повышенный контроль, включая дуальный контроль и separation of duties, 2-х факторная и прочее. Это работает, но: многие 2-х факторные работают через телефонный номер, который, при желании, нетрудно хайджекнуть и который, тащемта, сабскрайберу вовсе даже не принадлежит в большинстве случаев. Не говоря уже о том, что любая многофакторная идёт вразрез с convenience, и, следовательно, усложняет ведение бизнеса и снижает производительность. Он-премисес эта проблема куда менее остра и обычно все довольствуются юзернейм/пассворд внутри корп. сети: куда более удобно и достаточно безопасно.
Но это всё понятные "но", есть же, однако, целый слон в комнате которого в масштабах всей индустрии принято не замечать. Недавно прочитал документ на почти 100 страниц по стратегии входа в облака (откуда выход, как известно, рубль и об этом в таких документах пишут мало, если вообще, но это другой слон, размером поменьше) и там ни слова не оказалось про такую вещь, как риск компрометации со стороны вендора, а именно, дампы памяти тенантов.
Например, везде указывают такой контрол -- виртуальные диски будут (или могут быть) зашифрованы. Окэй. Что это за группа рисков, которую этот контрол адресует? Разумеется, это против угрозы типа "некто скорпировал ваш vhdx/vmdk и приатачил к своему hyper-v/ESXi". Т.н. сценарий "data at rest". Внимание, вопрос: "кто этот некто мог бы быть?". Разумеется, это навряд ли ваш сотрудник или его прохаканный аккаунт, т.к. если это он, то зачем ему париться с файлом? Ему проще скопировать данные с уровня приложения, на котором они уже заботливо дешифрованы облачным сервисом. Таким образом, эта группа рисков призвана адресовать сценарий rogue/прохаканный гипервизор или сотрудников облачного сервиса.
Но если этот контрол в стратегии и попадает, то лишь потому, что лежит на поверхности и об этом "люди спрашивают". О чём они не спрашивают, так это о сценарии "data in use". В почти любых гипервизорах, и никаких внятных защит против этого я толком не знаю, можно делать дампы памяти любых виртуалок. Разумеется, для этого нужно контролировать гипервизор, что вендору доступно по определению. В этих дампах куча паролей, доменные админы, например, те же пароли/ключи для шифрования дисков и прочая и прочая. Для почти всего этого есть в публичном доступе парсеры/дешифровщики, ну, например, для доменных админов хорошо справляется mimikatz. И это даже если пароль зашифрован (как в случае клиента актив дайректори), хотя и ключ шифрования/дешифрования лежит в том же дампе, почему это скорее обфускация, нежели шифрование, которое по определению бессмысленно без лежащей в его основе аутентификации. В целой массе случаев пароль лежит в памяти процесса плэйн текстом (напр. в юникоде). Делаешь дамп, ищешь юзернейм, недалеко смотришь на нечто похожее на пароль (для чего хорошо иметь возможность создавать юзеров, таким образом можно искать известный заранее пароль и далее разбираться в механизмах для общего случая). В крайнем случае долгий рисёч (для актив дайректори разобраться с механизмом заняло у хацкеров 12 лет, AD представлена в 1999, Беньямин Делпи представил мимикатз в 2012).
Вполне вероятно, что в масштабах 5-15 лет будет скандал масштаба всей индустрии (типа Сноудена) в котором обнаружится, что облачные вендоры массово и систематически шпионят за всеми тенантами путём снятия мемори дампов с тенантских виртуалок.
Например, есть такой сервис, AWS. И есть такой брэнд, Amazon Basics. Известный тем, что, через изучение маркета на своём собственном Амазоне, копирует наиболее успешные брэнды и выживает их с маркета. В их случае это имхо конфликт интересов -- владельцы общедоступного маркета также и торгуют на этом маркете и хайджэкают успешные товары. Кто им мешает шпионить за тенантами и хайджэкать их бизнесы?
Первоначально это обставят, или уже обставили, как шпионство для государства. Сами может и засцали бы (не совесть, разумеется, никакой совести нет, а вот аудиты...), а так, когда есть запрос из nsa то почему бы, раз уж всё равно будем разрабатывать для них шпиёнское решение, и самим не воспользоваться инфой? Да и государственное шпиёнство имеет длинную историю абьюза, в котором конкретные сотрудники аппарата преследуют свои личные бизнес-цели, для чего используют собранную для государственного шпионства инфу.
Здесь есть несколько переплетающихся трендов и конкретный ответ для конкретного тенанта будет разным.
Ну, например, патчинг в облаках, при прочих равных, будет лучше, чем он-премисес. Разумеется, возможны исключения, но хорошая и работающая патчинг программа в крупном энтерпрайзе стоит больших денег, как по софту, так и по людям, а главное, по культуре -- попробуй владельцу бизнес направления, который приносит фирме деньги, втолкуй, что отныне и навсегда его серверы будут перезагружаться минимум раз в месяц, а при out-of-band (т.е. в критических ситуациях, которые случаются неск. раз в год) так и вообще в произвольное время, будучи членом ИТ-направления, которое никаких денег не приносит ваще и только одни бесконечные расходы. Т.е. проблема патчинга в облаках не столько техническая, сколько психологическая, как и почти всё в ИТ. Человеческая природа, ебана.
Другой тренд это т.н. ubiquity, который есть часть определения облачных сервисов. Тоись, доступность отовсюду. А оно вам надо, чтобы кокойты хуй из Уганды или Нигерии или из России подбирал пароли к вашим аккаунтам? Чуть усложнив, через американский прокси? Разумеется, это никому не надо. Поэтому предлагается повышенный контроль, включая дуальный контроль и separation of duties, 2-х факторная и прочее. Это работает, но: многие 2-х факторные работают через телефонный номер, который, при желании, нетрудно хайджекнуть и который, тащемта, сабскрайберу вовсе даже не принадлежит в большинстве случаев. Не говоря уже о том, что любая многофакторная идёт вразрез с convenience, и, следовательно, усложняет ведение бизнеса и снижает производительность. Он-премисес эта проблема куда менее остра и обычно все довольствуются юзернейм/пассворд внутри корп. сети: куда более удобно и достаточно безопасно.
Но это всё понятные "но", есть же, однако, целый слон в комнате которого в масштабах всей индустрии принято не замечать. Недавно прочитал документ на почти 100 страниц по стратегии входа в облака (откуда выход, как известно, рубль и об этом в таких документах пишут мало, если вообще, но это другой слон, размером поменьше) и там ни слова не оказалось про такую вещь, как риск компрометации со стороны вендора, а именно, дампы памяти тенантов.
Например, везде указывают такой контрол -- виртуальные диски будут (или могут быть) зашифрованы. Окэй. Что это за группа рисков, которую этот контрол адресует? Разумеется, это против угрозы типа "некто скорпировал ваш vhdx/vmdk и приатачил к своему hyper-v/ESXi". Т.н. сценарий "data at rest". Внимание, вопрос: "кто этот некто мог бы быть?". Разумеется, это навряд ли ваш сотрудник или его прохаканный аккаунт, т.к. если это он, то зачем ему париться с файлом? Ему проще скопировать данные с уровня приложения, на котором они уже заботливо дешифрованы облачным сервисом. Таким образом, эта группа рисков призвана адресовать сценарий rogue/прохаканный гипервизор или сотрудников облачного сервиса.
Но если этот контрол в стратегии и попадает, то лишь потому, что лежит на поверхности и об этом "люди спрашивают". О чём они не спрашивают, так это о сценарии "data in use". В почти любых гипервизорах, и никаких внятных защит против этого я толком не знаю, можно делать дампы памяти любых виртуалок. Разумеется, для этого нужно контролировать гипервизор, что вендору доступно по определению. В этих дампах куча паролей, доменные админы, например, те же пароли/ключи для шифрования дисков и прочая и прочая. Для почти всего этого есть в публичном доступе парсеры/дешифровщики, ну, например, для доменных админов хорошо справляется mimikatz. И это даже если пароль зашифрован (как в случае клиента актив дайректори), хотя и ключ шифрования/дешифрования лежит в том же дампе, почему это скорее обфускация, нежели шифрование, которое по определению бессмысленно без лежащей в его основе аутентификации. В целой массе случаев пароль лежит в памяти процесса плэйн текстом (напр. в юникоде). Делаешь дамп, ищешь юзернейм, недалеко смотришь на нечто похожее на пароль (для чего хорошо иметь возможность создавать юзеров, таким образом можно искать известный заранее пароль и далее разбираться в механизмах для общего случая). В крайнем случае долгий рисёч (для актив дайректори разобраться с механизмом заняло у хацкеров 12 лет, AD представлена в 1999, Беньямин Делпи представил мимикатз в 2012).
Вполне вероятно, что в масштабах 5-15 лет будет скандал масштаба всей индустрии (типа Сноудена) в котором обнаружится, что облачные вендоры массово и систематически шпионят за всеми тенантами путём снятия мемори дампов с тенантских виртуалок.
Например, есть такой сервис, AWS. И есть такой брэнд, Amazon Basics. Известный тем, что, через изучение маркета на своём собственном Амазоне, копирует наиболее успешные брэнды и выживает их с маркета. В их случае это имхо конфликт интересов -- владельцы общедоступного маркета также и торгуют на этом маркете и хайджэкают успешные товары. Кто им мешает шпионить за тенантами и хайджэкать их бизнесы?
Первоначально это обставят, или уже обставили, как шпионство для государства. Сами может и засцали бы (не совесть, разумеется, никакой совести нет, а вот аудиты...), а так, когда есть запрос из nsa то почему бы, раз уж всё равно будем разрабатывать для них шпиёнское решение, и самим не воспользоваться инфой? Да и государственное шпиёнство имеет длинную историю абьюза, в котором конкретные сотрудники аппарата преследуют свои личные бизнес-цели, для чего используют собранную для государственного шпионства инфу.
