 |
||||||
 |
 |
|||||
 |
|
 |
|
 |
 |
 |
|
|||
 |
|||
 |
|||
 |
|||
 |
|||
Компьютерные гиганты идут в направлении тех же граблей с сервисами Google Health и Microsoft HealthVault. Разумеется, их privacy policy чёрным по белому утверждает, что только пользователь будет определять круг лиц с доступом к своим медицинским данным. Что ж, здесь хотя бы имеют место взятые на себя обязательства. А что же у нас? А у нас с полей победно рапортуют об электронизации страны: В скором времени в российских медучреждениях будут внедрены компьютерные медицинские системы, позволяющие заменить "бумажные" истории болезни на цифровые. Такие системы помогут значительно улучшить качество медицинского обслуживания: на 30-50% снизится количество врачебных ошибок, врачам станет проще разбираться в назначениях друг друга, а пациентам не придется тратить много времени в очередях в регистратуру и на прием. И ни слова о безопасности. Характерно, что истории болезни не относятся у нас к врачебной тайне как таковой, да и последняя формально не подлежит обязательной защите как приватная, сугубо личная информация. Лет пятнадцать назад я некоторое время жил в одном маленьком российском городке, где в то время местные компьютерные умельцы перевели медицинский архив главной горбольницы в электронный вид. Только о каком-либо контроле доступа подумать забыли, и все медицинские записи были доступны любому человеку с удалённым доступом к больничной интрасети (включая тамошних админов и членов их семей). Время было давнее, дикое. Теперь-то всё будет по-другому, ага. |
Тематика OLPC получила значительное внимание мировой прессы, поэтому я не стану рассматривать концепцию проекта в целом (интересующихся адресую, например, к недавней статье в Компьютерре), а сосредоточусь на, пожалуй, более интересном для читателей предмете: подсистеме безопасности детских компьютеров, получившей название BitFrost. Складывается впечатление, что разработчикам удалось создать одну из первых исключительно защищённых систем, при этом не накладывающей практически никаких ограничений на пользовательские характеристики операционной системы и ПО. На меньшее они и не могли пойти, ведь одна из главных целей OLPC -- позволить детям (даже больше: подвигать, провоцировать их) модифицировать, дорабатывать и перерабатывать свои системы, которые, в то же время, не должны приходить в негодность, если пользователь сделал что-нибудь не так или стал жертвой внешней атаки. К сожалению, цель была достигнута за счет несовместимости с существующим ПО. Наиболее распространённая сегодня концепция безопасности восходит своими корнями к первым UNIX-системам. Каждый файл там имел владельца и подчинялся набору правил доступа, определявших, кто мог читать его, изменять или исполнять (владелец мог делать всё). С незначительными различиями от ОС к ОС эта идея сохраняется поныне. Однако то, что было рационально и достаточно более 30 лет назад в досетевую эпоху, уже не является таковым в сегодняшнем объединённом мире. Проблема в том, что в большинстве случаев исполняемое приложение обладает тем же объёмом привилегий, как и сам исполняющий его пользователь: если пользователь запустит вредоносную или просто небезопасную программу (сознательно или даже под влиянием социальной инженерии, что особенно реально для целевой аудитории OLPC), это может поставить под угрозу все его данные просто потому, что программа способна делать всё, что угодно, стоит лишь её запустить. Исключение составляют разве что программы, исполняемые в ограниченной среде виртуальных машин, "песочниц". Разработчики BitFrost и XO (операционной системы ноутбука) взяли за основу именно идею "песочницы". Запускаемая программа не получает автоматический доступ ко всем ресурсам системы, а только к тем, которые она запросила в момент установки (что предотвращает ущерб от последующей эксплуатации "дырявой" программы другим приложением). Хитрость в том, что программа (особенно программа злонамеренная) не может затребовать все ресурсы разом -- ряд прав доступа являются взаимоисключающими, и авторы прибегли к серьёзному анализу, чтобы одновременно обеспечить безопасность системы и работоспособность программ (которые могут писать и сами дети). Таким образом, если, к примеру, пользователь устанавливает программу-плеер, ей будет предоставлен read-only-доступ ко всем музыкальным файлам в системе (и только к файлам этого типа), однако, программа не сможет вместе с этим запросить доступ к сетевому интерфейсу. В обычных условиях программа имеет доступ только к собственным файлам приложения и временных файлов: всё ПО запускается в своей chroot-директории и не "видит" ничего вне её пределов (необходимые библиотеки мэппятся внутрь директории). Программы не могут работать с пользовательскими файлами напрямую. Вместо этого они полагаются на объектно-ориентированный интерфейс хранилища данных. Иными словами, программа не может использовать системные вызовы read()/write() для доступа к произвольным файлам, не может даже просмотреть список файлов ребёнка (за исключением случая, когда программе требуется доступ к файлам определённого типа на чтение, что было описано выше). Если программе нужно открыть определённый пользовательский файл, она делает запрос к центру безопасности XO, который, в свою очередь, выводит на экран диалоговое окно открытия файла. Когда пользователь выбирает файл, система делает его копию-на-запись в директорию временных данных программы и передаёт программе путь к файлу внутри chroot-директории. В итоге, файл как бы появляется в доступном для программы пространстве, но даже если будет удалён программой, можно будет восстановить его из исходной копии. Аналогичная концепция опосредованного доступа к определённым ресурсам применяется и в других ситуациях. Например, программа, даже запросившая доступ к веб-камере при инсталляции, не сможет активировать её самостоятельно -- это бы представляло угрозу приватности. Вместо этого программа передаст запрос к центру безопасности XO, а уже это доверенное приложение спросит пользователя, разрешить ли программе сделать это. В то же время, разработчики старались насколько это возможно минимизировать число различных запросов к пользователю (ведь зачастую ребёнок не способен сделать обдуманный рациональный выбор относительно собственной безопасности и целостности ПК): любое недопустимое действие должно просто блокироваться системой. Здесь были приведены лишь несколько значимых элементов BitFrost. Всем заинтересованным читателям рекомендую обратиться к спецификациям системы, где она описана в больших деталях, не перегруженных техническими подробностями (разработчики планируют выпустить техническую документацию позднее). Это исключительно интересная концепция, которая с неизбежностью будет реализована в других системах, по крайней мере частично. А что касается проекта OLPC, то подозреваю, что будущие обладатели этих ноутбуков, повзрослев, ещё дадут фору своим сверстникам из более благополучных стран. |
Читатели моего блога достаточно компетентны в сетевых технологиях, но всё-таки для начала приведу пару слов о принципах действия динамических веб-сайтов. Когда вы открываете подобный сайт (скажем, интернет-магазин), он автоматически присваивает вам случайный номер, называемый идентификатором сессии (этот номер сохраняется в cookie браузера и передаётся сайту при открытии каждой страницы). Он служит как опознавательный знак для веб-сайта, дабы он мог отличать вас, когда вы переходите от страницы к странице, и на каждой странице отображать, к примеру, ваше персональное меню или корзину с покупками, выбранными ранее. Вся эта информация -- персональное меню, покупки -- размещается на диске сервера во временном файле, одноимённом с номером сессии. К сожалению, за всем этим удобством скрывается угроза безопасности: если злоумышленник сумеет тем или иным образом узнать номер вашей текущей сессии, он сможет передать его с собственного компьютера и эффективно выдать себя за вас и, как следствие, получить доступ ко всем вашим приватным данным на данном веб-сайте. В заключение отмечу, что однажды присвоенная сессия действует не вечно: если вы не проявляете активность на сайте в течение некоторого времени (обычно, часа), она аннулируется; однако файл сессии может быть удалён очень нескоро! Итак, возвращаемся к поставленной задаче. Поскольку при авторизации на сайте пароль открыто передаётся через Сеть, наблюдателю на канале связи ничего не стоит перехватить его, чтобы в дальнейшем входить на сайт под именем легитимного пользователя. Таким образом, цели, преследуемые в данной работе: - защита от пассивных атак, т.е. простого прослушивания трафика между пользователем и сайтом с целью перехвата пароля; - защита от активных атак, т.е. более открытых действий злоумышленника, направленных, к примеру, на захват текущей авторизованной сессии. Перед потенциальным злоумышленником также стоят две альтернативные цели: - задача-минимум: захватить сессию легитимного пользователя; - задача-максимум: раскрыть пароль пользователя. Наиболее элегантное и простое решение здесь -- SSL, обеспечивающий шифрование всего трафика между пользователем и сайтом на транспортном уровне, а также аутентификацию сайта. Как уже отмечалось, это сравнительно дорого... Альтернатива На этапе аутентификации пользователя для входа на сайт можно применить простой протокол "запрос-ответ", не раскрывающий пароль на канале связи. Для этого потребуется реализовать миниатюрное приложение на javascript, обеспечивающее необходимые преобразования на стороне пользователя. Как часто бывает в таких описаниях, роль пользователя выполнит Анна, а сервера -- Борис; числовые индексы переменных обозначают номер этапа, значение которого принимает переменная. Протокол может выглядеть так: 1) Анна инициирует начало протокола (для этого ей нужно открыть страницу с формой для ввода имени и пароля). Вместе с этим, Борис определяет IP-адрес Анны (который ещё пригодится), а также присваивает ей (передаёт) идентификатор неавторизованной гостевой сессии -- sid. 2) Далее Борис генерирует и отправляет Анне r = H(k,t1,ip1), где H -- операция хэширования, k -- секретный показатель, известный только Борису, t1 -- метка времени начала исполнения протокола, ip1 -- IP-адрес Анны, определённый на этапе 1. Кроме того, Борис сохраняет ip1 и t1 в переменных сессии Анны.3) Анна вычисляет h = H(r,u,p), где u и p -- её логин и пароль, соответственно.4) Анна возвращает Борису h,u,sid1 5) Время поступления ответа на этапе 4 сравнивается с меткой времени, сохранённой на этапе 2. Если ответ получен в допустимом интервале, исполнение протокола продолжается. 6) Борис по u извлекает из базы данных пароль Анны p. 7) Борис самостоятельно вычисляет h' = H( H(k,t1,ip4), u4, p6) 8) Борис сравнивает h, полученный от Анны на этапе 4, с h', вычисленный им самим на этапе 7. 9) При их соответствии Борис генерирует новый идентификатор авторизованной сессии sid', помещает ip4 в переменные сессии и сообщает sid' Анне. Векторы атак Попробуем атаковать протокол с различных направлений. В роли пользователя снова выступит Анна, сервером будет Борис, Николай -- пассивным наблюдателем, Виктор -- активным взломщиком. На начальном этапе Николай, находясь на канале связи между Борисом и Анной, может определить идентификатор сессии, присвоенный Анне. Это не даёт ему преимуществ, поскольку пока это сессия неавторизованного гостя, не обладающего привилегиями. Этап 2, опять же, не сообщает Николаю ничего полезного. Хотя он знает IP Анны и может угадать метку времени, он не имеет представления о секретном ключе Бориса, используемом для имитозащиты передаваемых данных. Когда на этапе 4 Анна возвращает свои подсчёты серверу, Николай видит лишь очередной хэш, не несущий информации о пароле. Хотя ему известны и значение r (перехваченное на этапе 2), и логин Анны, он никогда не видел её пароль, так что его восстановление из h равносильно (в идеале) полному перебору результата функции хэширования. Получается, что у Николая не слишком много шансов определить пароль Анны, и наша основная задача -- скрыть пароль на канале связи -- выполнена. Но может быть взлом удастся более смелому Виктору, обладающему также более серьёзными ресурсами для нападения? У него есть несколько вариантов. Например, он мог бы попытаться подделать значение h, передаваемое на этапе 4, но, не зная пароль Анны, это бесперспективно -- Борис выявит расхождения в пересчитанном h' на восьмом этапе. Виктор мог бы вклиниться в протокол на этапе 9 и перехватить идентификатор авторизованной сессии. Однако если Анна включила в настройках openSpace привязку сессии к IP, такая смена адреса (поскольку легитимный адрес Анны Борис сохранил в переменных сессии) тут же приведёт к инвалидации сессии. Казалось бы, вариантов нет. Но вместо всего этого шаманства Виктор пойдёт самым простым путём, известным как "атака гроссмейстера". Расположив свой компьютер на канале связи между Борисом и Анной, он атакует протокол с самого первого этапа. Когда Анна запрашивает с сайта страницу логина (инициирует протокол), Виктор перехватывает запрос и пересылает его от своего имени (т.е. со своего IP). В результате Борис назначает Виктору гостевой идентификатор sid Анны. Виктор, притворившись Борисом, пересылает идентичные данные от себя к Анне (запрошенную страницу и sid). Анна вычисляет ответ на запрос Бориса и возвращает его наряду с остальными данными. Виктор вновь пассивно ретранслирует эту информацию Борису. Тот проверяет правильность ответа, используя IP, хранящийся в сессии и убеждается в том, что ответ получен он Анны, ведь пароль должна была знать только она. Следовательно, Борис создаёт авторизованную сессию и возвращает её номер источнику запроса -- Виктору! Здесь нет возможности определить, что источник не тот, за кого себя выдаёт; и даже после авторизации сессия не будет прервана, поскольку IP источника (Виктора) идентичен на всех этапах протокола. Чтобы успешно завершить нападение Виктор лишь должен вернуть Анне от имени Бориса какую-нибудь стандартную ошибку HTTP и прервать связь, чтобы она списала всё это на проблемы с сервером. Контрзащита К сожалению, я не вижу иного пути улучшить этот протокол, кроме следующего: 1) Анна инициирует исполнение протокола. Борис узнаёт её IP и присваивает ей гостевой sid. 2) Борис посылает r = H(k,t1) 3) Анна вычисляет и возвращает Борису h = H(r,u,p,ip), u, sid1, где ip -- известный ей самой IP-адрес её машины.4) Борис по u извлекает из базы данных пароль Анны p. 5) Борис вычисляет h' = H( H(k,t1), u3, p4, ip3), используя для ip3 источник ответа, полученного на этапе 3.6) Борис сравнивает h и h', при соответствии которых помещает ip3 в переменные новой авторизованной сессии, а её идентификатор возвращает Анне. Что будет, если и теперь Виктор попытается транслировать сообщения между участниками протокола, а в конце захватить авторизованную сессию? На этапе 3 он перехватывает значение h. Не зная пароля Анны он не может изменить его, поэтому передаёт Борису в исходном виде. Разумеется, Борис получает IP Виктора в качестве источника ответа и использует этот IP на этапе 5, повторно вычисляя хэш. В итоге, на этапе 6 Борис обнаруживает расхождения и прерывает протокол. Проблема здесь в том, что для данного протокола любой посредник -- будь то легитимный прокси, NAT или исходящий узел сети Tor -- также расценивается нападающим. В этом случае можно, к примеру, предоставить Анне самостоятельно указать на третьем этапе IP, соединение с которого Борис примет. В общем, это просто тренировка для ума, и весьма маловероятно, что подобное будет реализовано на практике. Но всё же, какие ещё есть недостатки или потенциал для улучшения? |
Спам, изначально определявшийся как "незапрошенная рассылка рекламного характера, произведённая неопределённому кругу получателей по электронной почте", давно вышел за пределы такого понятия. Все мы в периоды предвыборных кампаний получаем свою порцию спамерского политического пиара, причём не только по электронной почте, но и в ICQ, и даже в интернет-форумах. Спам теряет границы прежних формальных определений, по сути превращаясь в любую незапрошенную информацию с отсутствующим либо фальсифицированный источником распространения. Современное ПО худо-бедно справляется со спамом в электронной почте, используя для этого целый арсенал технологий со сложными названиями вроде фильтров Байесса или нечётких сигнатур. К сожалению, программы мгновенных сообщений, такие как ICQ, до сих пор серьёзно обойдены вниманием разработчиков антиспамерского ПО, и пользователей пока спасают лишь владельцы IM-сетей, контролирующие спам на центральных серверах либо отсекая спамеров, периодически меняя сетевые протоколы (что попутно создаёт проблемы для пользователей альтернативных клиентов вроде Trillian и Jabber-систем, на время теряющих свясь с этими сетями и пользователями проприетарных клиентов). Ещё более трудная ситуация складывается для веб-мастеров публичных ресурсов. Как только веб-сайт обретает достаточную популярность, его коммьюнити-средства -- форумы, доски объявлений, вики и гостевые книги -- наводняются такими же сообщениями, которые всякий среднестатистический пользователь ежедневно в некотором количестве выгребает из почтового ящика. Веб-мастеры не располагают готовыми средствами, оставаясь с этой проблемой, как правило, один на один. До недавнего времени самым простым и действенным решением проблемы "спама гостевых книг" (когда автоматические роботы публикуют в форумах, гостевых книгах и других подобных ресурсах коммерческую рекламу или ссылки на определённые сайты с целью повысить их индекс цитирования) было введение обязательной регистрации пользователей: прежде чем получить возможность публиковать сообщения, пользователь должен зарегистрироваться на сайте и, возможно, подтвердить указанный при регистрации email. Такое решение имеет и свою оборотную сторону: не каждый человек захочет тратить время на регистрацию, чтобы задать в форуме один единственный вопрос. Альтернатива этому методу -- планомерная ежедневная чистка ресурса от мусорных сообщений. Обычно, когда объём спама превышает некоторый лимит терпения или после особо отъявленных спамерских атак, от такого способа отказываются в пользу первого. Повесть о настоящем человеке Однако существует и компромиссный вариант. Как известно, в сегодняшнем мире спам рассылается не людьми (за редкими исключениями), а специальными программами. Для публикаций в форумах используются агенты-"пауки", наподобие тех, что применяются поисковыми системами. Они переходят между сайтами по ссылкам в поисках характерных признаков форумов: строк с названиями форумных движков, форм размещения сообщений и регистрации, а затем заполняют эти формы сгенерированными или заданными сообщениями и отправляются дальше. В итоге нам просто нужен способ, позволяющий отличить человека от такого "робота", либо сильно осложнящий жизнь последним. Методика таких тестов была придумана "отцом" современной вычислительной техники Аланом Тьюрингом. Суть теста Тьюринга заключается в создании задачи, для решения которой компьютеру требуются существенные вычислительные ресурсы в сравнении с лёгкостью решения той же задачи человеком, и обычно сводится к распознаванию образов (согласно известному афоризму, не в пример компьютеру, отличить кошку от собаки по внешнему виду может даже трёхлетний ребёнок). Вероятно, самый простой вариант такого подхода, -- это статичная картинка с сильно зашумлённым (растянутым, перевёрнутым, искривлённым) текстом, размещённая рядом с формой для публикации сообщения. Кроме самого сообщения посетитель должен перепечатать в специальное поле этот зашумлённый текст, который при отправке сообщения будет сравнен с эталоном. Этот вариант хорош до тех пор, пока ваш форум в силу популярности, например, не становится предметом целенаправленных атак спамеров: когда спамер-человек вручную укажет своей программе текст, который она должна перепечатать в форму, защита перестанет работать. Более удачный, долговечный и универсальный вариант -- это скрипт, автоматически генерирующий такие уникальные тексты для каждого пользователя. Для преодоления подобной защиты у спамера будет два варианта: либо научить программу решать тест Тьюринга "на лету", либо заставить её находить решение теста "грубой силой", т.е. перебирая все возможные решения. Если скрипт не тривиален, т.е. генерируемый им текст получается достаточно зашумлённым (но, в то же время, и не настолько, чтобы определить текст не смог даже человек), длинным (не одна-две буквы) и случайным (не словарь из пары дюжен слов), то его решение в любом случае превысит возможную выгоду спамера от публикации сообщения в данном форуме и станет просто невыгодным. Опыт - сын ошибок трудных Спам начал активно публиковаться в форуме "PGP в России" около полутора лет назад. Поток был невелик, и мы с другими участниками-модераторами успешно его изгоняли, хоть периодически и плевались и размышляли над возможным решением. Сильный всплеск произошёл в конце минувшего года: в некоторых разделах форума появлялись десятки сообщений от незарегистрированных пользователей -- спамовых роботов. Примерно на месяц в форуме пришлось ввести обязательную (вернее, принудительную) регистрацию. А полным решением проблемы, позволившим оставить форум открытым и, одновременно, отсечь роботов, стал скрипт freeCap. freeCap -- это реализация концепции CAPTCHA (от Completely Automated Public Turing test to Tell Computers and Humans Apart, т.е. полностью автоматизированный публичный тест для разделения компьютеров и людей): скрипт генерирует сильно зашумлённую картинку с некоторым случайным текстом, который, тем не менее, человек способен различить, чтобы доказать свою человеческую сущность. Этот мощный бесплатный скрипт нашёл широкое применение как на сайте "PGP в России", так и в этом блоге, тоже пострадавшем однажды от спамеров. И внедрить его в создаваемую или установленную систему не составит труда ни одному веб-мастеру, имеющему хотя бы поверхностное представление о программировании на PHP. Установка достаточно проста. Во-первых, нужно скачать архив с последней версией скрипта. Распакуйте его, внесите необходимые на ваш взгляд настройки в файл freecap.php и загрузите на свой сервер. Второй шаг -- привязка скрипта к веб-приложению. Для этого вам потребуется внедрить в код своей программы три фрагмента php-кода, ответственных за обработку теста. Первый из них -- это обработчик сессии. Его разумно включить в ту часть кода вашего приложения, которая берёт на себя формирование или вывод страницы с формой для публикации сообщений. <?php // CAPTCHA session start session_start(); if(!empty($_SESSION['freecap_word_hash']) && !empty($_POST['word'])) { if($_SESSION['hash_func'](strtolower($_POST['word'])) == $_SESSION['freecap_word_hash']) { $_SESSION['freecap_attempts'] = 0; $_SESSION['freecap_word_hash'] = false; $word_ok = "yes"; } else { $word_ok = "no"; } } else { $word_ok = false; } // CAPTCHA session end ?> Второй фрагмент представляет собой html-код, который будет выводить автоматически генерируемое скриптом изображение теста Тьюринга и поле, куда пользователь (или особо умный робот) должен будет ввести текст, прочитанный им на картинке. Можно разместить этот код в той же форме, через которую производится публикация сообщений, чтобы за валидацию теста и ввод сообщения отвечал один и тот же скрипт. Впрочем, возможны и иные варианты. <!-- CAPTCHA input start --> Введите код подтверждения:<br /> <input type="text" name="word" maxlength="20" /><br /> <img src="/freecap/freecap.php" id="freecap" vspace="5" /> <!-- CAPTCHA input end --> Третий заключительный фрагмент -- это валидатор теста. Это простое условие, передающее обработку дальнейшим процедурам, если получает в переменной волшебное слово, указывающее на прохождение теста, либо выводящее ошибку. Логично разместить этот фрагмент в скрипте, обрабатывающем форму ввода сообщения, непосредственно перед процедурами, вводящими сообщение в базу данных. <?php // CAPTCHA validation start if ($word_ok != "yes") { print"Неверный код подтверждения!"; } // CAPTCHA validation end ?> Если ваше приложение (к примеру, форум) допускает добровольную регистрацию пользователей, желательно окружить этот и предыдущий блоки условием, запрещающим вывод и валидацию теста для зарегистрированных участников. Так ваши постоянные посетители смогут сохранить всё удобство общения, не отвлекаясь на решение теста. |
Все мы бываем в банках. Банк -- помимо того, что кридитно-финансовая организация, привлекающая и инвестирующая средства клиентов, еще и сложная система информационной, физической и экономической защиты хранящихся наличных и перечисляемых безналичных денег. Экономическая безопасность строится на процедурах подтверждения и контроля транзакций, информационная -- на средствах и методах защиты сведений о транзакциях, персональных, финансовых и прочих данных, а физическая -- на построении и поддержании безопасного физического периметра вокруг охраняемых объектов: зданий, помещений и денежных средств. Но, несмотря на слаженность всего процесса, заключительные решения всегда принимают люди: охранник решает, пустить ли через КПП сотрудника, забывшего пропуск; операционист решает, действительно ли перед ним владелец этого паспорта и счета; кассир решает, нет ли в полученном ордере ничего подозрительного. Сбой может произойти в любом месте, причем не только из-за активных действий злоумышленника, но и по невнимательности или халатности сотрудника банка -- звена системы безопасности. Недавно я был в банке, потому что должен был зачислить на свой счет некоторую сумму наличных. Операционист проверил мой паспорт, сравнил фотографию с моей внешностью, взял мою книжку и выписал приходный ордер на нужную сумму. Те же данные были продублированы в информационной системе банка, а подписанный мною ордер вместе с книжкой передан в кассу. Я же получил жетон с номером, под которым моя транзакция значилась в системе, и должен был предъявить его кассиру, чтобы тот обработал нужный ордер. Всем эта процедура хорошо знакома; она может немного различаться между банками, но общий принцип таков. Пройдя в кассу, я выполнил свою часть протокола и передал жетон кассиру (не выкладывая деньги в кювету, пока меня не попросят). Та просмотрела мой ордер, расписалась в нем и в книжке и... достала из сейфа несколько пачек купюр и начала поочередно скармливать их счетной машинке. Мне стало интересно, в какой момент девушка поймет ошибочность своих действий, и не прервал ее благородный порыв. И только когда она развернулась, чтобы переложить пересчитанные деньги в кювету, деликатно заметил, что не рассчитывал на такой подарок к 8 марта, а пришел положить деньги на счет, не обналичивать их. Пару секунд девушка в замешательстве смотрела на меня, потом загляну в ордер и, перекрестившись, поблагодарила, что спас ее от увольнения. Банковская система в большой мере полагается на государственные механизмы предупреждения, контроля и реагирования. Даже если бы я, выражаясь компьютерными терминами, не прервал выполнение сбившегося протокола, а довел его до конца и покинул банк с удвоенной суммой, это, в реальности, не привело бы в дальнейшем ни к чему, кроме конфискации суммы моего "необоснованного обогащения". Последнее звено безопасности ненадежно: оно дает случайные сбои и сильно подверженно различным воздействиям и влияниям. Вот почему контроль и реагирование не менее важны, чем предупреждение нападений и сбоев. |
 |
