Здравствуйте, Sharov, Вы писали:
S>А как вообще расследуются инциденты взлома в облаке? И как понять кого взломали, т.е кто виноват, если каждая из сторон -- пользователь и aws -- кивают друг на друга?
Я думаю, что никак они не расследуются. Т.к. мало кто что то реально критическое в сторонних облаках располагает. Считают статистику, располагают разные там общественно ориентированные порталы (с открытой информацией), бак энд каких нибудь кабинетов клиентов по паставке запчастей и всего такого прочего, частично — бухгалтерию, просчеты рисков, анализы подобного всего.
ну а все реально критическое — транзакции банковские, весь продакшен по разработке изделий, все это во внутренней сети, на своей территории и на своем железе.
Поэтому даже если и взламывают — то в общем, особо и брать то нечего.
Здравствуйте, Grizzli, Вы писали:
G>ну а все реально критическое — транзакции банковские, весь продакшен по разработке изделий, все это во внутренней сети, на своей территории и на своем железе.
Я тут уже написал, что секретные банковские транзакции вполне себе считаются на облаках.
Здравствуйте, Sharov, Вы писали:
C>>В США предпочитают считать деньги. Мне неизвестны факты утечки данных из AWS, и зная внутренние меры безопасности, я этим ничуть не удивлён. S>А как вообще расследуются инциденты взлома в облаке? И как понять кого взломали, т.е кто виноват, если каждая из сторон -- пользователь и aws -- кивают друг на друга?
В большинстве случаев взлом заключается в том, что клиентский ключ утёк хакеру. У Амазона есть стандартная процедура для этого — все узлы останавливаются, аккаунт блокируется, логи вызовов отправляются в соответствующее ведомство.
Для очень серьёзных клиентов, в контракте прописана возможность аудита доверенной третьей стороной.
Здравствуйте, Cyberax, Вы писали:
C>В большинстве случаев взлом заключается в том, что клиентский ключ утёк хакеру. У Амазона есть стандартная процедура для этого — все узлы останавливаются, аккаунт блокируется, логи вызовов отправляются в соответствующее ведомство.
А если aws чего-нибудь вовремя не пропатчили или не установили обновление, или это все на совести пользователя? Т.е. aws за настройкой софта вообще не следит?
Хакер использовал какой-нибудь эксплойт и получил рута. Кто виноват?
G>нет. просто никто секретные разработки и модели не будет на сторону отдавать, чтобы там не гарантировали.
А никто модели не отдаёт. Я как-то работал на проекте где вполне себе ценная инфа считалась во вполне обычном облаке. Не кад, но матрицы здоровенные и тоже надо было считать. Так солвер — был просто решателем который просто брал матрицу [много тыщ x много тыщ] из файла и в другой файл складывал результат. Хоть весь солвер по битикам разбери — без знания как входной файл получился — хер ты вообще узнаешь, это был юнит-тест солвера или реальное решение чего-то там. Даже зная что это реальное решение — ты фиг узнаешь это было правильное решение или в модели был косяк и это решение будет отправлено в утиль. Даже зная что решение было правильное — хрен ты восстановишь модель, потому что при подготовке какие-то вещи могли выкинуть совсем или заменить на константы (например потому что уже посчитано в предыдущих расчётах), какие-то формулы изменили до неузнаваемости (ибо нужная функция почти линейна на том диапазоне в котором ищется решение), и т.п. В общем просто числодробить в облаке вполне можно.
Здравствуйте, Sharov, Вы писали:
C>>В большинстве случаев взлом заключается в том, что клиентский ключ утёк хакеру. У Амазона есть стандартная процедура для этого — все узлы останавливаются, аккаунт блокируется, логи вызовов отправляются в соответствующее ведомство. S>А если aws чего-нибудь вовремя не пропатчили или не установили обновление, или это все на совести пользователя? Т.е. aws за настройкой софта вообще не следит?
AWS не следит за пользовательскими узлами. По желанию клиенты могут установить Amazon SSM и дать возможность Амазону устанавливать обновления. Но это всё чисто оционально.
S>Хакер использовал какой-нибудь эксплойт и получил рута. Кто виноват?
Если хакер получил доступ к узлу пользователя, используя какую-то уязвимость в ПО пользователя, то это не проблемы Амазона.
Проблема Амазона будет, если кто-то использует эксплойт для получения доступа в родительский домен Xen/KVM и оттуда попадёт в виртуалки других пользователей на этом же аппаратном узле. Мне такие случаи неизвестны, и у Амазона есть достаточно действенные меры по предотвращению этого.
Здравствуйте, Cyberax, Вы писали:
G>>еще раз. все эти рендеринги, все эти расчеты финансовой статистики и рисков (которые в облаках поди без привязки к id пользователям просчитываются) — это все мелочи. военка, тяжелое производство, у них особые требования к секретности. C>Какие "особые требования"? Схемы истребителей классифицированы как "secret" в США. Это означает, что они могут обрабатываться на Azure.
Так это схемы штатовских истребителей.
C>Да ну? В России — может быть, так как правовой нигилизм и пофигизм у всех.
Ты реально думаешь, что кто-то поверит американцам что они не сольют все интересные схемы?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Да ну? В России — может быть, так как правовой нигилизм и пофигизм у всех. WH>Ты реально думаешь, что кто-то поверит американцам что они не сольют все интересные схемы?
Здравствуйте, Anton Batenev, Вы писали:
C>> Проблема Амазона будет, если кто-то использует эксплойт для получения доступа в родительский домен Xen/KVM AB>Если не секрет, а в какой приблизительно пропорции используются XEN/KVM и почему (т.е. почему поддерживается две системы вместо одной)?
Все типы инстансов, запущенные после 2016-го года (семейства c4, c5, m4, m5...) — на KVM.
Используется из-за того, что KVM оказался намного более гибким и лучше масштабируется. В частности, в Xen очень примитивный планировщик, тогда как KVM использует стандартный линуксовый.
Здравствуйте, hi_octane, Вы писали:
G>>нет. просто никто секретные разработки и модели не будет на сторону отдавать, чтобы там не гарантировали.
ну это какой то частный случай. основные кады отдают все — в своем или нейтральном формате (там вариантов просто других и нет), CAE/СFD тоже отдают практически все.
Здравствуйте, Cyberax, Вы писали:
C>Я тут уже написал, что секретные банковские транзакции вполне себе считаются на облаках.
Аналитика на обезличенных счетах, а не хранение данных клиентов и совершение операций с счетами клиентов.
Разные вещи — как в Боинге, аналитику по запчастям считают в облаках, весь серьезный продакшен и проектирование — только во внутренних закрытых сетях.
Здравствуйте, Grizzli, Вы писали:
C>>Я тут уже написал, что секретные банковские транзакции вполне себе считаются на облаках. G>Аналитика на обезличенных счетах, а не хранение данных клиентов и совершение операций с счетами клиентов.
Конкретно банковские операции торайдиционно считают на мейнфреймах, так как там нагрузки по нынешним меркам смехотворные.
А вот, например, расчёты рисков опционов — считают в облаке, так как нужно дофига мощности. И это намного более секретные данные, чем размер остатков на счетах.
G>Разные вещи — как в Боинге, аналитику по запчастям считают в облаках, весь серьезный продакшен и проектирование — только во внутренних закрытых сетях.
Вот не надо мне рассказывать что они и как считают — сам видел.
Здравствуйте, Cyberax, Вы писали:
C>А вот, например, расчёты рисков опционов — считают в облаке, так как нужно дофига мощности.
Какие расчеты? Я году в 2005-м занимался разработкой сервиса, который занимался оценкой рисков портфелей (которые и опционы включали, естественно) на потоке. Оно и тогда прекрасно работало без облаков (если не считать 5-6 мощных серваков в разных локациях облаком ).
Здравствуйте, Lexey, Вы писали:
L>Какие расчеты?
ОТC options, где риски есть к сотням переменных, а модель считается через монте-карло.
L>Я году в 2005-м занимался разработкой сервиса, который занимался оценкой рисков портфелей (которые и опционы включали, естественно) на потоке. Оно и тогда прекрасно работало без облаков (если не считать 5-6 мощных серваков в разных локациях облаком ).
Зависит от портфеля, но в любом инвест.банке внутреннее облако по расчету опционов это 500+ очень нехилых серваков. При это бизнес хочет гонять больше сценариев, но не может, потому что ценник не могут себе позволить даже банки размера JPM.
Здравствуйте, Lexey, Вы писали:
C>>А вот, например, расчёты рисков опционов — считают в облаке, так как нужно дофига мощности. L>Какие расчеты?
Рисков. Многие опционы и сделки с ними настолько сложные, что рассчитываются только через Монте-Карло.
Здравствуйте, novitk, Вы писали:
N>ОТC options, где риски есть к сотням переменных, а модель считается через монте-карло.
ОК, принимается. В моем случае оценивались только биржевые позиции и ордера.
L>>Я году в 2005-м занимался разработкой сервиса, который занимался оценкой рисков портфелей (которые и опционы включали, естественно) на потоке. Оно и тогда прекрасно работало без облаков (если не считать 5-6 мощных серваков в разных локациях облаком ). N>Зависит от портфеля, но в любом инвест.банке внутреннее облако по расчету опционов это 500+ очень нехилых серваков.
Я вживую наблюдал, как в инвестиционном подразделении одного очень известного российского банка такие вещи считались ровно на 1 (очень мощном, да) сервере. И, внезапно, даже на на плюсах, а на шарпе. Правда, там ориентация была на крупный бизнес, а не на массового клиента, так что портфелей было не очень много.
N>При это бизнес хочет гонять больше сценариев, но не может, потому что ценник не могут себе позволить даже банки размера JPM.
И подобные хотелки были. Но не для расчета опционов, а просто для симуляции пачки рисковых факторов. И речь шла не об облаке, а о десятке, максимум, машинок.
Здравствуйте, Lexey, Вы писали:
N>>ОТC options, где риски есть к сотням переменных, а модель считается через монте-карло. L>ОК, принимается. В моем случае оценивались только биржевые позиции и ордера.
Если речь идет о оценки цены портфеля для биржевой (listed) позиции, то это просто сложение/умножение и расходов на математику тут 0, вся проблема в латентности и организации данных в памяти/базе. Облако тут не поможет.
N>>При это бизнес хочет гонять больше сценариев, но не может, потому что ценник не могут себе позволить даже банки размера JPM. L>И подобные хотелки были. Но не для расчета опционов, а просто для симуляции пачки рисковых факторов. И речь шла не об облаке, а о десятке, максимум, машинок.
Необходимость в облаке зависит от сложности модели. Если есть сложная стохастическая нелинейная модель, не дай бог требующая MC, то куча машин будет необходима. Если все статично и линейно, то можно и в Ехcel-e посчитать.
Здравствуйте, novitk, Вы писали:
N>Если речь идет о оценки цены портфеля для биржевой (listed) позиции, то это просто сложение/умножение и расходов на математику тут 0, вся проблема в латентности и организации данных в памяти/базе.
Нет, речь об расчете риска перед постановкой нового ордера на биржу. Математика там была настолько не нулевая, что ее приходится сознательно по времени ограничивать (сначала считать быстрым, но грубым алгоритмом, потом все более и более точными и медленными, останавливаясь, когда время вышло).
N>Необходимость в облаке зависит от сложности модели. Если есть сложная стохастическая нелинейная модель, не дай бог требующая MC, то куча машин будет необходима.
Ну вот, в той реальности, что я видел, обходились одной. Расчет шел несколько часов.
).
