Previous Entry Share Next Entry
photo25

Eventual Security

к вопросу о способах обьять необьятное

Оригинал взят у jakobz в Eventual Security
Есть такой термин - Eventual Consistency. По-умному - это когда ради масштабируемости жертвуют какими-либо гарантиями насчет корректности и сохранности данных, в надежде разгрести возникающие проблемы в фоне (что, как правило, означает положить на них хуй). По факту, "Eventual Consistency" - больше про развод, чтобы продать хипстерам очередную монгу.

Так вот, я в кровавом энтерпрайзе пользуюсь симметричным подходом - Eventual Security. Работает так: не закрываем всякие дырки типа "сюда может любой послать запрос и обойти права доступа" - это дорого и сложно. Проще писать жесткий аудит - кто, что, и когда делал. И затем, постфактум, выдавать пизды, если что.

Пара моментов:
- людей надо иметь возможность найти и взять за яйца. Т.е. Eventual Security не работает для систем, выставленных мордой в инет
- чтобы не было вопросов, надо везде на видном месте обозначать что за вами следят. Ну типа ненавязчиво: "last updated by Ivan Ivanov 30.09.2015". Это выполнит ту же роль, что и замочек на один тык, но который переквалифицирует просто кражу, в кражу со взломом.
- на чтение того что не положено, естественно, надо все ходы закрывать наглухо


  • 1
sassa_nf September 30th, 2015
"это когда ради масштабируемости жертвуют какими-либо гарантиями насчет корректности и сохранности данных, в надежде разгрести возникающие проблемы в фоне"

что там бывает на самом деле - это одно. Но есть класс задач, которые по-другому и не решишь.

Мир не транзакционален не только потому, что монга, а потому, что не везде есть даже возможность их добавить.

VM стартует. В БД отображается состояние гостевой VM. Существует ненулевой промежуток времени между собственно запуском VM и отображением этого факта в БД. (Тогда гость уже может начать что-то ворушить, а другие компоненты пугаются, что получают запросы от неживого еще гостя)

VM упало. Существует ненулевой промежуток времени между собственно нарушением работоспособности и отображением этого факта в БД.

(Deleted comment)
sassa_nf September 30th, 2015
конечно, это application-specific состояние, но я для примера. Суть-то в том, что даже нотификации нет - только poll по факту. Но и нотификация вопрос не решает; процесс failure ну никак не транзакционный.

juan_gandhi September 30th, 2015
О, я это в гугле в варзях делал. Каждый может пойти и изменить значение. И это будет написано на странице - такой-то руку приложил, тогда-то.

109 September 30th, 2015
всё правильно. я людям часто объясняю, что эквивалентное определение eventual consistency - это когда в любой момент времени какие-то данные (и в их числе могут быть те, с которыми надо работать прямо сейчас) неконсистентны. меняет отношение моментально.

(Deleted comment)
vinslivins September 30th, 2015
1 предупреждать невнимательных сотрудников что это не освобождает от ответственности разруливания последствий
2 а всё равно кто-нибудь знает чужой пароль, у кого-то осталась кодобаза с захаркожеными ключами, итп. много чего на доверии например в той же среде программистов
3 тут п.1
4 в этом случае вряд ли поможет формочка, которая пишет Пете или Васе что он неправ. Вася скажет что он друг директора, и ему нужны права на систему, а поскольку сейчас ему некогда - сами сделайте что ему надо.

Edited at 2015-09-30 09:57 pm (UTC)

sergiej September 30th, 2015
"- чтобы не было вопросов, надо везде на видном месте обозначать что за вами следят. Ну типа ненавязчиво: "last updated by Ivan Ivanov 30.09.2015". Это выполнит ту же роль, что и замочек на один тык, но который переквалифицирует просто кражу, в кражу со взломом."
ещё круче решать это дело через намёк на "суперсекретную фичу" какой-нибудь сплетливой особе о том, что все просмотры всех экранов логируются. И через неделю вся контора будет боятся открывать карточку клиента "просто так" :) Проверено, работает.

  • 1
?

Log in

No account? Create an account