...

суббота, 5 мая 2018 г.

[Из песочницы] Кросс-языковая разработка ПО

Задача


Вот бы, разрабатывая программу на одном языке, сразу получать исходники на других языках программирования… Я пишу на C# .NET, но в последнее время всё больше требуется интегрироваться с Java. Одно из решений — оформление web-сервисов для взаимодействия, но не то это, не то. Вроде и существуют конвертеры C# в Java, но эксперимент показал, что для реального проекта они (те, что удалось попробовать) не работают, хотя на «hello world» отрабатывают отлично. Переписать с нуля на Java весь проект нереально — он активно разрабатывается более 6 лет (Pullenti — обработка естественного языка), да и на C# он нужен. Пришлось мобилизоваться и в прошлом году написать этот конвертер, а в этом году и конвертер C# в Python.

Опыт создания конвертера C# в Java


Итак, на входе проекты (solution) Visual Studio, нужно получить классы на Java. Разумеется, не все типы проектов возможно поддержать, но тип «Class Library» и «Console Application» — вполне. Проекты не должны использовать никакие графические библиотеки типа System.Drawing, никакие Windows-возможности или DllImport, а для используемых библиотек должны существовать аналоги в Java. К счастью, для используемых мной возможностей такие аналоги нашлись (работа с XML, архивы GZip и др.). От некоторых несущественных деталей пришлось отказаться, немного подправив алгоритмы. На уровне языка C# и Java близки, но Java чуть беднее — вот что в нём отсутствует:
  • property { get; set; } — приходится работать с функциями;
  • struct — структуры отсутствуют, поэтому сначала я их моделировал просто классами Java, но затем переписал алгоритм, отказавшись от них полностью;
  • delegate — отсутствуют, но моделируются интерфейсом с одной функцией;
  • event — моделируется массивом ArrayList из элементов класса, реализующего интерфейс соответствующего delegate;
  • out и ref аргументы у методов — моделируется классами с одним полем Value;
  • internal — этот модификатор вообще не имеет смысла в Java, так как отсутствует понятие сборки, поэтому просто заменяется на public;
  • new Class() { присваивания } — приходится создавать статическую функцию, в которую выносить эти присваивания;
  • enum — если в C# возможны побитовые операции с его элементами, то в Java это запрещено, и конвертеру приходится enum преобразовывать в классы Java;

Но не это оказалось самое сложное — проблема с огромным количеством системных функций, для которых нужно было искать аналоги. Для некоторых аналогов не нашлось, и пришлось писать их на Java, создавая свою библиотечку, которая добавляется при генерации к результирующим исходникам Java. Например, в C# для потоковых операций ввода-вывода есть базовый класс Stream, а в Java два отдельных класса InputStream и OutputStream, и поэтому нужна некоторая «обёртка» над ними.

Если нужно было исключить из кода C# некоторый фрагмент или оформить его немного по-другому для Java, то использовались директивы препроцессора #if JAVA… #else… #endif.
Вот так, постепенно дополняя конвертер новыми функциями и подправляя исходный код на C#, удалось прийти к тому, что генерируемые на Java более чем 1500 юнит-тестов стали отрабатывать правильно, как и их прототипы на C#.

Сравнение скорости работы .NET и Java


Теперь самое интересное. Есть трудоёмкий алгоритм (в основном работа со строками), и абсолютно идентичные его реализации на C# и Java. Как «апологет» .NET, я всегда сомневался в эффективности Java. Но оказался неправ — C# всего на 15-20% быстрее Java (запускал из Eclipse под Windows), а не в несколько раз, как ожидалось. А какова ситуация с Python? Читайте дальше.

Опыт создания конвертера C# в Python


В Python оказалось конвертироваться даже проще, чем в Java. Основа была готова, осталось только подправить генератор на новый язык и найти (написать) аналоги используемых функций.

Что в Python отсутствует или неудобно:

  • for(init, cond, incr) — в полноценном виде отсутствует, есть некоторые частные случаи с range, но в основном приходится моделировать через while;
  • switch — отсутствует, моделируется if-then-else-ами;
  • interface — отсутствует, но это просто класс с пустыми методами;

Очень неудобная система импорта других классов, приводящая в ряде случаев к циклической зависимости и невозможности импорта вообще. Приходилось отслеживать эти зависимости и выносить некоторый импорт на уровень методов, а не всего файла с классом. Несмотря на эти и другие сложности, удалось добиться правильного отрабатывания тех 1500 юнит-тестов.

Сравнение скорости работы .NET и Python


Многие жалуются на низкую скорость работы Python, но насколько она низка? И низка ли? Пришло время сравнить на том же алгоритме, что и для Java (точнее, на тех же юнит-тестах). Готовы? Итак, Python работает в 30 раз медленнее, чем .NET.

Причина, думаю, в следующем. В Python отсутствуют простые типы как ValueType (насколько я понял), и даже обычные числа — это полноценные объекты (фактически как boxing в .NET). И элемент строки — это не символ, а тоже строка из одного символа! То есть string[i] — это не char, а как бы string.Substring(i, 1) в .NET.

Технология кросс-языковой разработки


На основе личного опыта скажу, что возможно разрабатывать на одном языке и платформе и автоматически переносить на другие языки и платформы. Свой базовый проект разрабатываю на .NET Framework 4.0, и в любой момент имею функционально эквивалентные:
  • исходники на Java (конвертер);
  • исходники на Python (конвертер);
  • проекты на .NET Core (отдельные csproj-файлы, но исходники те же);
  • проекты на .NET Framework 2.0 (конвертер, и такое нужно для одного заказчика);

Поделюсь одной полезнейшей возможностью Visual Studio, которой почему-то мало пользуются даже профессиональные разработчики C#, к моему глубокому удивлению. И которая отсутствует в средствах разработки, скажем, для Java. А именно — возможность изменять код и перемещать текущую позицию прямо в ходе выполнения, причём состояние всех переменных сохраняется и можно продолжить выполнение с учётом внесённых изменений. Это кардинальным образом облегчает отладку, особенно когда для воспроизведения нужной ситуации требуется некоторое время. Например, я включаю режим, при котором Visual Studio приостанавливает программу в месте возникновения Exception (вернее, я этот режим никогда не отключаю), запускаю длительную обработку, а через сколько-то минут или часов возникает эта ситуация, чаще всего NullReference. Я исправляю код, и вместо того, чтобы перезапускать программу, перемещаю точку выполнения на нужный оператор назад и запускаю выполнение дальше. Да и вообще частенько я прямо в ходе выполнения реализую сложные алгоритмы в нужных местах. Помнится, когда делал систему биржевой торговли, то это на порядок облегчало жизнь в условиях трудоёмкой процедуры инициализации и выхода на нужную алгоритмическую ветвь. В Visual Studio эта возможность достигается за счёт тесной интеграции IDE и компилятора — они могут себе такое позволить. Но вернёмся к технологии.

Ограничения очевидны — только библиотеки и консольные приложения. Почти нереальны конечные приложения с пользовательским GUI или Web-приложения. Да и при разработке библиотек приходится придерживаться ограничений, накладываемых требованием универсальности. От чего-то придётся отказаться, что-то переписать, но результат стоит затраченных усилий!

Let's block ads! (Why?)

[Перевод] Правдоподобная реконструкция Инстаграм-подобных фильтров

Существует куча софта, который позволяет пользователям применять различные цветовые фильтры к своим фотография. Пионером в этом деле был Инстаграм и иногда хочется сделать в своем приложении уже знакомые пользователям фильтры. И я хочу представить набор утилит, который позволит в полу-автоматическом режиме очень точно воспроизводить цветовые фильтры из других приложений в своём приложении.


https://github.com/homm/color-filters-reconstruction

Людям нравятся фильтры из Инстаграма. Они пытаются воспроизвести их снова и снова. И снова и снова. И снова и снова. Проблема с этими попытками в том, что люди пытаются вручную подобрать цветовую коррекцию, которая будет хоть как-то похожа на то, что делают оригинальные фильтры. Для меня же было намного более интересно попробовать воспроизвести фильтры основываясь на более надежных методах и математике. И похоже, что это единственная попытка действительно точного воссоздания цветовых фильтров.

Для примера, одно из следующих изображений было получено с применением фильтра Clarendon на оригинальном изображении в самом Инстаграме, а другое с помощью наложения восстановленного фильтра. Попробуйте угадать, какое восстановлено.

Для сравнения, это результат применения того же фильтра из коммерческого набора «Инстаграм-подобных фильтров», который вы без труда сможете нагуглить:

Данный фильтр с натяжкой можно назвать похожим на оригинальный.


Как это работает

Метод основан на трехмерных цветовых таблицах поиска (3D color LUT) и их двумерном представлении — изображениях Халда. Основная идея очень простая — образец изображения Халда с равномерным распределением цвета обрабатывается с помощью исходного фильтра, цветовые трансформации которого требуется воспроизвести. Обработанное таким образом изображение Халда может быть использовано для очень точной аппроксимации цветовых трансформаций исходного фильтра.

Полученное изображение Халда может быть использовано в целом ряде программ и библиотек, таких как GraphicsMagick или Photoshop. Также его можно использовать в приложениях для macOS и iOS с помощью библиотеки CocoaLUT. Кроме того, изображение Халда может быть конвертировано в формат 3D LUT куба, который очень распространен в приложениях для обработки видео. И небольшой спойлер: поддержка 3D color LUT появится в следующей версии Pillow 5.2 для Питона.


Ограничения

Этот метод может захватывать только однородные преобразования цвета. Любые царапины, градиенты, виньетирование и прочие текстуры, накладываемые поверх изображения, не попадут в реконструкцию и даже будут мешать правильной реконструкции. Также реконструкция получается не очень правдоподобной, если исходный фильтр действует по-разному в разных областях изображения.

Тем не менее, на мой взгляд, этот метод максимально правдоподобно восстанавливает 32 из 40 инстаграмовских фильтров (если не считать виньетирование, наложить которое не представляет труда уже после обработки) и с переменным успехом позволяет добиться чего-то похожего для оставшихся восьми.


Требования

Для генерации и конвертирования изображений Халда вам понадобится интерпретатор Питона с pip.

$ git clone https://github.com/homm/color-filters-reconstruction.git
$ cd color-filters-reconstruction
$ pip install -r requirements.txt 

После получения изображений Халда, вам уже не понадобится никакой софт из этого репозитория. Зато понадобится какая-либо библиотека, которая умеет их применять. Это может быть GraphicsMagick, которая имеет биндинги для большинства популярных языков, включая Python, Ruby, PHP, JavaScript™, а также интерфейс командной строки.


Руководство


  1. Для начала вам потребуется создать единичное изображение. Просто выполните:

    $ ./bin/generate.py
    

    Вы увидите файл с названием hald.5.png. Число в имени файла — это квадратный корень из размера таблицы поиска. То есть 5 означает, что файл содержит таблицу размером 25×25×25 элементов.


    Этот файл немного отличается от привычного представления изображений Халда. В нем таблица реплицирована 4 раза и добавлены отступы. Кроме того, каждая ячейка таблицы занимает не один пиксель, а квадрат 8×8 пикселей. Всё это сделано, чтобы противостоять различным искажениям, как самого исходного фильтра, так и сжатия JPEG.


  2. Обработайте единичное изображение с помощью исходного фильтра. Если речь об Инстаграме, то единичное изображение нужно загрузить в мобильное устройство и опубликовать с наложением интересующего фильтра. После этого в фотопотоке появится обработанное единичное изображение. Его и нужно забрать с устройства обратно.


    Важно, чтобы разрешение полученного изображения с фильтром было точно таким же, как у исходного единичного изображения.


  3. Сконвертируйте изображение с фильтром в настоящее изображение Халда:

    $ ./bin/convert.py raw/1.Clarendon.jpg halds/
    

    Здесь halds/ — директория, куда попадёт полученный фильтр.


  4. Вы великолепны! Полученный фильтр сразу же можно применять к любым другим изображениям.

    $ gm convert sample.jpg -hald-clut halds/1.Clarendon.png out.jpeg
    



Дополнительные советы

Хотя настройки по умолчанию в большинстве случаев позволяют получить высококачественные фильтры Халда, бывают ситуации, когда этого недостаточно.

Некоторые нежелательные эффекты могу появляться, если исходный фильтр имеет сильные искажения на локальном уровне или заметные градиенты в центре изображения. Самый заметный неприятный эффект — одноцветные полоски. Вот, например, оригинальное изображение и изображение, полученное после обработки восстановленным фильтром Hudson, в котором наиболее заметны эти проблемы:

# Создать изображение Халда из обработанной Инстаграмом картинки
$ ./bin/convert.py raw/15.Hudson.jpg halds/
# Применить изображение Халда к другому изображению
$ gm convert girl.jpg -hald-clut halds/15.Hudson.png girl.15.jpg

На обработанном изображении объекты выглядят плоскими и пастеризованными: лицо, волосы, стулья на заднем плане. Хотя пастеризация и является довольно распространенным эффектом в обработке изображений, она не была частью исходного фильтра Hudson.

Если вы внимательнее посмотрите на единичное изображение с примененным фильтром Hudson, вы заметите, что оно довольно шумное. И это является источником проблемы.


К счастью, можно попросить утилиту convert.py применить трехмерное Гауссово размытие к таблице поиска во время конвертации, что уменьшит шум. Для этого нужно поставить пакет SciPy (входит в поставку macOS по умолчанию).

# Следующую строку нужно выполнить только один раз
$ pip install scipy
$ ./bin/convert.py raw/15.Hudson.jpg halds/ --smooth 1.5
$ gm convert girl.jpg -hald-clut halds/15.Hudson.png girl.15.fixed.jpg

Как видите, все неприятные эффекты ушли. Вы можете найти другие опции у convert.py, выполнив ./bin/convert.py --help.

Удачи с обратной инженерией!

Let's block ads! (Why?)

(Законы Акина) законы космической инженерии

1. Инженерная разработка — это цифры. Анализ без цифр — это просто мнение.

2. Создание правильной ракеты занимает бесконечное количество времени. Поэтому следует создавать ракеты, в которых что-то неправильно.
3. Конструирование — циклический процесс. Количество итераций всегда на одну больше, чем уже было. Это верно на любой стадии.

4. Ваши лучшие наработки в окончательном решении будут не нужны. Привыкните жить с этим.

5. (Закон Миллера) Три точки — это уже кривая.

6. На логарифмической бумаге всё есть прямая.

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

8. В природе оптимум почти всегда в середине. Не доверяйте утверждениям, в которых оптимум в районе экстремума.

9. Недостаток информации ещё не причина откладывать анализ решения.

10. Не уверен — решай приблизительно. Но обязательно вернись к решению, когда появятся настоящие цифры.

11. Иногда самый быстрый путь к выполнению проекта — всё выкинуть и начать сначала.

12. Единственно верного решения не существует. Хотя существует много неверных.

13. Разработка базируется на требованиях. Нет причины делать что-то хоть капельку «лучше», чем указано в требованиях.

14. (Закон Эдисона) «Лучшее» враг «хорошего».

15. (Закон Ши) Все возможности для улучшения решения обычно кроются в стыках. Стыки же и основное место для «косяков».

16. Люди, которые обдумывали эту задачу до вас, не имели прямой связи с мудростью предков. Поэтому не стоит думать, что их решение было лучше вашего. Тем более не стоит выдавать его за своё.

17. То, что решение было опубликовано, не делает его более верным.

18. Опыт проверяет решения в жизни. Слишком много проверки жизнью может обречь казалось бы неплохие решения.

19. Вероятность того, что вы намного умнее всех в своей области, очень невелика. Если в ваших расчётах финальная скорость вышла в две скорости света, то вы, возможно, изобрели телепорт, но скорее всего вы просто накосячили.

20. Плохое решение с хорошим отчётом — со временем будет отвергнуто. Хорошее решение с плохим отчётом будет отвергнуто сразу.

21. (Закон Ларраби) Половина того, чему вас учили преподаватели — полная чушь. Осталось разобраться, которая половина. В этом суть образования.

22. Если сомневаешься — документируй. (Потребность в документации достигает максимума вскоре после закрытия программы).

23. Расписание срока работ, которое вы составите, всегда кажется отвлечённой фантастикой, пока заказчики не уволят вас за его несоблюдение.

24. Это называется «Work Breakdown Structure» (порядок разбивки работы), потому что вы будете Work пока не настанет Breakdown, и придётся внедрить какой-то Structure.

25. (Закон Баудена) После провала испытаний, всегда можно улучшить расчёты, показав, что негативная вероятность присутствовала изначально.

26. (Закон Монтемерло) Don't do nuthin' dumb — не надо делать фигню!

27. (Закон Варси) Сроки смещаются только в одну сторону.

28. (Закон Рэнжера, иногда ошибочно Закон Хайнлайна) TANSTAAFL: There ain't no such thing as a free launch. Примерно переводится как «Бесплатно кормят только на убой» или «бесплатно просто так не покормят».

29. (Закон управления проектами фон Тисенхаузена) Чтобы получить примерно точные окончательные требования по программе, умножьте значения начальных требований на число Пи, и сдвиньте десятичную точку на одно положение вправо.

30. (Закон инженерных решений фон Тисенхаузена) Если хотите, чтобы ваш вклад в конструкторскую разработку инженерной системы был максимальным, научитесь рисовать. Инженеры всегда в конце концов делают что-то похожее на картинку концепт-художника.

31. (Закон эволюционной разработки Мо) Нельзя добраться до луны, залезая с каждым разом на более высокое дерево.

32. (Закон демонстраций Аткина) Когда всё работает как надо, действительно важные посетители не приходят.

33. (Закон планирования програм Паттона) Хороший план насильно исполненый сейчас, лучше чем идеальный на следующей неделе.

34. (Закон планирования задач Рузвельта) Делай что можешь, там где ты есть, с тем что под рукой.

35. (Закон дизайна Сент-Экзюпери) Дизайнер знает, что достиг совершенства, ни тогда когда уже нечего добавить, а когда уже нечего убрать.

36. Обычный инженер делает элегантные системы. Хороший инженер — работающие. Настоящий инженер — эффективные.

37. (Закон Хэншоу) Важнейшая вещь в успехе программы это чётко выстроить ряды виновных.

38. Возможности повышают требования, игнорируя ограничения из учебников.

39. Любая космическая программа, в которой «оказалась» разработка новой ракеты, по факту есть программа разработки новой ракеты.

39. (альтернативная формулирока) Три правила сохранения космических програм в пределах бюждета и сроков:

1) Никаких новых ракет.
2) Никаких новых ракет.
3) Делайте что угодно, только никаких новых ракет.

40. (Закон Мак-Брайена) Не надо улучшать то что ещё не заработало.

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

42. Космос совершенно не прощает ошибок. Если инженер ошибся то кто-то погибнет (и нет такой вещи как «частичная вина», мол, в основном-то решение было правильным).

Оригинал

Let's block ads! (Why?)

Громкий звук системы пожаротушения вывел из строя диски в дата-центре Nasdaq

В шведском дата-центре Digiplex, который используется Nasdaq для осуществления операций в Северной Европе, в середине апреля произошел серьезный сбой. Вышли из строя жесткие диски многих серверов. Причиной стала неверно настроенная система пожаротушения — она издавала при работе крайне громкий звук, который привел к повреждениям дисков.

Что случилось


Традиционно я дата-центрах и технических помещениях используются системы тушения, работающие при помощи инертного газа — это позволяет потушить пожар, не повредив оборудование водой или пеной. Однако при неверной настройке подобной системы, ее работа может сопровождаться крайне громким звуком, возникающим при выходе газа из баллонов. А такие звуки могут вывести из строя жесткие диски, что и произошло в дата-центре Digiplex.

Как удалось выяснить изданию Bleeping Computer, система тушения сработала случайно, пожара в действительности не было. В результате инцидента вышли из строя серверы Nasdaq, а также скандинавских банков FIM Bank и OP Bank Group.

Простой в результате сбоя составил около пяти часов — после этого инженеры Nasdaq Nordic запустили резервную систему. При этом представитель компании заявил, что для замены всего вышедшего из строя оборудования «не хватит серверов во всей Швеции», и его придется импортировать из других стран.

Не первые проблемы из-за громкого звука в ЦОД


Инциденты, подобные сбою в дата-центре Nasdaq, случались и ранее. К примеру, в сентябре 2016 года громкий звук системы пожаротушения на десять часов вывел из строя дата-центр румынского ING Bank.

Негативное влияние громких звуков на работу жестких дисков подтверждается различными исследованиями. К примеру, эксперименты экспертов компании IBM подтвердили тот факт, что в некоторых случаях работа систем пожаротушения на инертном газе может приводить к подобным проблемам.

Другие материалы по теме финансов и фондового рынка от ITI Capital:


Let's block ads! (Why?)

пятница, 4 мая 2018 г.

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 1: «Вступление: модели угроз», часть 3

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 1: «Вступление: модели угроз», часть 2

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год


Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3

Если вы думаете, что правительство преследует вас, проблемы безопасности будут гораздо серьёзнее, потому что ваш компьютер может содержать в себе вредоносное физическое устройство независимо от того, какие программы на нём установлены. Поэтому вам следует тщательно подходить к созданию модели угрозы, сбалансировав её наилучшим образом против конкретного противника. Я думаю, что противостояние АНБ обойдётся вам слишком дорого, но если вы пытаетесь защитить свой домашний каталог «Афина» от других студентов, можно особо не беспокоиться. Так что создание оптимальной модели угроз выглядит как балансировка между различными требованиями безопасности.

Другой пример плохой модели угрозы представляет собой способ обеспечение Интернет-безопасности проверкой сертификатов тех сайтов, на которые вы заходите.

В этих SSL/TLS протоколах, когда вы подсоединяетесь к сайту, в адресной строке показывается значение HTTPS, то есть «защищённое соединение». Имеется в виду, что данный сайт получил сертификат безопасности, подписанный одним из центров сертификации, и который подтверждает, что да, этот ключ принадлежит действительно Amazon.com.

С точки зрения архитектуры, ошибка модели угрозы заключается в том, что она предполагает, что все эти центры авторизации СА заслуживают доверия, и они никогда не совершат ошибку. Но на самом деле, существуют сотни СА: у Индийского почтового управления есть свой центр авторизации, и у китайского правительства он есть, и так далее. И любой из этих центров может сделать сертификат безопасности для любого хоста или домена. В результате, если вы плохой парень и хотите дискредитировать Gmail или взломать их сайт, вам нужно просто скомпрометировать один из этих центров авторизации. И для этого всегда можно найти СА в не слишком развитой стране. Таким образом, создавать модель угрозы на основе предположения, что все сертифицированные сайты безопасны, неправильно. Потому что неправильно предположение о том, что безопасны все 300 центров авторизации, разбросанные по всему земному шару.

Однако, не смотря на это, современный протокол SSL до сих пор использует такое предположение в основе своего механизма безопасности для обозревателей Интернета.

Существует множество примеров такого рода, когда угроза приходит оттуда, откуда её не ждали. Забавным примером из 80-х годов может служить проект, осуществляемый DARPA — Управлением перспективных исследовательских проектов Министерства обороны США. Тогда им очень хотелось создать неуязвимые операционные системы, и они привлекли к этому кучу университетов и исследователей, которые должны были разработать прототипы безопасных ОС.

После этого они создали команду «плохих парней», которые должны были любым способом взломать эти безопасные системы. В результате оказалось, что сервер, на котором хранились исходные коды всех ОС, находился на компьютере в совершенно незащищённом офисе. «Плохие ребята» без труда взломали этот сервер, изменили исходный код и создали на его основе лазейку в ОС. Затем, когда исследователи построили свои операционные системы, эти фальшивые хакеры воспользовались лазейкой и взломали их без особого труда.

Поэтому вам действительно нужно подумать обо всех возможных предположениях, касающихся того, откуда приходит ваше программное обеспечение, и того, как плохой парень может в него проникнуть, чтобы убедиться, что ваша система действительно безопасна. В конспектах лекций есть много примеров на эту тему.

Вероятно, самая распространённая проблема встречается в механизмах безопасности. Отчасти это потому, что механизм осуществления безопасности – самая сложная её часть. Это совокупность программного и аппаратного обеспечения и других компонентов системы, которые осуществляют вашу политику безопасности. И причины, по которым этот механизм может сломаться, неисчислимы.

Так что большая часть наших лекций будет посвящена именно механизмам безопасности, тому, как создавать механизмы, обеспечивающие правильное применение политик безопасности. Также мы поговорим о политике безопасности и моделях угроз.

Выясняется, что намного проще создавать ясные и чёткие принципы разработки механизмов, понимать, как они работают или не работают, чем заниматься политиками и моделями угроз, которые вам необходимо «вписать» в содержимое конкретных систем.

Рассмотрим некоторые примеры ошибок при создании механизмов безопасности. О последнем случае вы могли услышать пару дней назад – он касается проблем с механизмом безопасности облачного сервиса iCloud от Apple. Любой, у кого есть iPhone, может пользоваться сервисом iCloud. Этот сервис представляет собой облачное хранилище файлов, и если вы потеряете свой «айфон», то ваши файлы всё равно сохранятся в этом облаке, он поможет вам найти свой телефон, если вы его потеряли, и содержит в себе ещё множество полезных функций. Я думаю, что этот iCloud «родственник» сервиса me.com, который был создан по такой же схеме несколько лет назад.
Проблема, которая была обнаружена в iCloud, заключалась в том, что создатели не использовали одинаковый механизм безопасности для всех интерфейсов. Рассмотрим, как выглядит этот сервис.

К сервису iCloud подключены различные службы, такие как «Хранилище файлов», «Фотоархив», «Поиск телефона» и так далее. Все эти службы проверяют, являетесь ли вы правильным пользователем, прошли ли вы правильную аутентификацию. Вероятно, к разработке этого сложного сервиса были привлечены разные исполнители, которые создавали разные интерфейсы безопасности для входящих в него служб. Например, в службе «Find My iPhone» не отслеживалось, сколько раз подряд вы пытались авторизоваться в системе. Эта функция очень важна, так как ранее я уже упоминал, что люди не утруждают себя созданием действительно сильного пароля.
На самом деле система, которая производит аутентификацию пользователей с помощью паролей, довольно «хитрая», мы поговорим об этом позже. Но существует одна хорошая стратегия, заключающаяся в том, что из миллиона подобранных паролей найдется один, который точно подойдёт к чему-то аккаунту. Так что если вы сможете создать миллион вариантов пароля для данного аккаунта, вероятно, вы сможете в него зайти, потому что люди не утруждают себя созданием сложных паролей.

Поэтому одним из способов защиты от подбора пароля является то, что система не позволяет вам предпринимать неограниченное количество попыток входа в аккаунт несколько раз подряд. Возможно, что после 3-х или 10 неудачных попыток система активирует тайм-аут и предложит вам попытаться ввести пароль снова через 10 минут, а то и через час. Это действительно тормозит хакера, так как он может предпринять за день всего несколько попыток подбора пароля вместо миллиона. И даже если у вас не слишком трудный пароль, злоумышленнику будет трудно его подобрать из-за больших потерь времени.

Но в интерфейсе «Find My iPhone» такая функция не предусмотрена. «Плохой парень» может отправить за день миллион пакетов с паролем, взломать эту службу и украсть конфиденциальные данные пользователя iCloud, что и имело место.

Это пример того, что у вас была правильная политика безопасности – только правильный пользователь и правильный пароль может дать доступ к файлам. У вас даже была правильная модель угрозы безопасности, что плохие парни будут пытаться угадать пароль, поэтому нужно этому промешать, ограничив количество попыток ввода. Однако разработчик сервиса просто облажался, потому что его механизм безопасности содержал ошибку. Он просто забыл применить правильную политику и правильный механизм в одном интерфейсе.

И такое появляется снова и снова в самых разных системах, где просто один раз ошиблись, и это отразилось на безопасности всей системы. Существует много ошибок такого рода, например, когда разработчик забыл проверить контроль доступа в целом.

Например, у City Bank есть сайт, который позволяет вам просмотреть информацию вашей кредитной карты. То есть если у вас есть карта этого банка, вы заходите на сайт и он говорит вам:

«да, у вас есть эта кредитная карта, вот ваши операции» и так далее. Несколько лет назад рабочая процедура заключалась в том, что вы заходите на какой-то сайт, вводите свой логин и пароль и вас перенаправляют на сайт, который, скажем, имеет адрес, например: citi.com/account?id=1234. Оказывается, какой-то парень догадался, что если вы просто поменяете эти цифры, то свободно зайдёте в чужой аккаунт. Вот и непонятно, что думать о разработчиках подобной системы?

Возможно, эти парни думали правильно, но забыли проверить, как работает их функция безопасности на странице аккаунта, то есть что не только у меня может быть правильный ID номер, но он также может быть ID номером того парня, который только что авторизовался. Это важная проверка, но они про неё забыли.

Или, может быть, разработчики думали, что никто не сможет воспользоваться этим URL, кроме вас? Может, у них просто была плохая модель угрозы? Может они подумали, что если они не напечатали этот адрес в виде ссылки, то никто не сможет по нему «кликнуть»? Это пример плохой модели угрозы. Может быть и так, в любом случае трудно сказать, чем они руководствовались, выпустив такой продукт. Такие ошибки часто случаются, причём даже маленький, незаметный промах в механизме безопасности способен привести к печальным последствиям.

Ещё один пример, которых не так много в ошибках проверки идентификации, представлен проблемой, выявленной у смартфонов Android несколько месяцев назад. Эта проблема была связана с биткоинами, я уверен, что вы слышали о них – это электронная валюта, довольно популярная в наши дни. Способ, благодаря которому работает система Bitcoin, достаточно продвинутый – это то, что ваш баланс связан с использованием персонального ключа. Поэтому, если у вас есть чей-то персональный ключ, вы можете потратить его биткойны. Безопасность Bitcoin основывается на предположении, что никто не знает вашего ключа. Это как с паролем, только ещё важней, так как люди могут предпринять множество попыток разгадать ваш ключ. При этом нет никакого реального сервера для проверки ключей. Это просто шифрование. Поэтому любой компьютер может попробовать расшифровать ключ, и если это получится, они смогут перевести ваши биткоины кому-то другому. Поэтому чрезвычайно важно генерировать надёжные, сложные ключи, которые никто не сможет разгадать.

Есть люди, которые пользуются своими биткоинами со смартфона под управлением Android. Существует мобильное приложение на API Java под названием SecureRandom, которое генерирует случайные значения ключей для Bitcoin. Однако люди выяснили, что в действительности это совсем не случайные числа. Это приложение содержит генератор псевдослучайных чисел, или PRNG. SecureRandom задаёт ему начальный массив из нескольких сотен случайных битов, которые PRNG может «растянуть» на столько случайных битов, сколько захотите. То есть сначала вы используете исходный массив, некий «посевной материал», а затем генерируете из него любое желаемое количество битов, то есть взращиваете свой урожай ключей.

Благодаря различным криптографическим принципам, не буду в них углубляться, это действительно работает. Если вы изначально предоставите этому PRNG несколько сотен действительно случайных битов, будет чрезвычайно сложно угадать, какие псевдослучайные числа он сгенерирует. Но проблема заключается в том, что в этой библиотеке Java была небольшая ошибка. При определённых обстоятельствах она забывала снабдить PRNG исходными значениями, и массив состоял из одних нулей. Это означало, что любой мог узнать, какие случайные числа PRNG сгенерировал для ваших ключей. Если они начинаются с нулей, значит, они генерируют одинаковые значения, и взломщик с легкостью получает такой же персональный ключ, как у вас. То есть он просто генерирует ваш ключ и распоряжается вашими биткоинами.
Это ещё один пример того, как вроде бы небольшая ошибка механизма безопасности может привести к катастрофическим результатам. Многие люди из-за этого потеряли свои биткоины. Конечно, такие ошибки на каком-то уровне исправляются, можно изменить имплементацию Java в приложении SecureRandom так, чтобы оно всегда заполняло PRNG случайным массивом исходных битов. Но в любом случае, это служит ещё одним примером ошибочной работы механизма безопасности.

Вопрос из аудитории:

— Объясните, отличается ли это от атаки на алгоритм создания цифровой подписи DSA?

Ответ:

— В действительности проблема намного сложнее, чем то, на что вы намекаете. Проблема в том, что даже если вы не сгенерировали свой ключ сначала на Android устройстве, конкретная схема подписи Bitcoin предполагает, что каждый раз, когда вы генерируете новую подпись с помощью этого ключа, вы используете одноразовый свежий, или как его ещё называют, «nonce» исходник для такой генерации. И если вы когда-нибудь сгенерируете две подписи на основе одного одноразового исходника, кто-то сможет повторить ваш ключ.

Эти случаи похожи, но различаются деталями. Если вы сможете сгенерировать ключ где-то ещё, кроме Android, и это будет действительно надёжный ключ, то каждый раз, когда вы попытаетесь сгенерировать 2 подписи из одного и того же nonce или случайного значения, кто-то сможет путём сложных математических вычислений просчитать ваши подписи и извлечь из них ваш открытый ключ. Или, что ещё важнее, персональный ключ.

Я хочу ещё раз отметить, что любая деталь в компьютерной безопасности имеет важное значение. Если вы совершите кажущуюся несущественной ошибку, например, забудете что-то проверить, или забудете инициализировать случайный массив исходных данных, это может иметь серьёзные последствия для всей системы.

У вас должно быть чёткое представление того, каковы особенности, характеристики вашей системы, что она должна делать и какие неожиданности скрываются за углом. В этом смысле хорошо подумать о том, как можно взломать вашу систему, прощупать её со всех сторон, например, что произойдёт, если я предоставлю слишком свободный доступ, или какой самый «несвободный» из всех свободных доступов я могу оставить? Какого рода данные я должен поместить в свою систему, чтобы заткнуть всевозможные бреши?

Одним из хороших примеров такой двусмысленности являются SSL сертификаты, которые зашифровывают имена в сам сертификат. Это проблема отличается от проблемы, связанной с доверием к СА. SSL-сертификаты – это просто последовательность байтов, которые вам посылает веб-сервер. Внутри этого сертификата находится имя ресурса, к которому вы подсоединяетесь, например, Amazon.com. Вы знаете, что вы не можете просто записать эти байты. Вам надо как-то зашифровать их и указать, что это Amazon.com, и разместить их в конце строки.

Так вот, в SSL сертификатах используется определённая схема шифрования, которая записывает Amazon.com, сначала записав количество байтов в строке.

Отлично, сначала их нужно записать. Пусть у меня будет 10 байтовая строка под названием Amazon.com, оно действительно состоит из 10 байтов. Замечательно. У нас имеется 10 байт, которые представляют собой буквы названия и точку, а за и перед этими 10 байтами в строке могут располагаться ещё какие-то знаки.

Затем браузер, который написан на языке С, берёт эти байты в обработку. Этот язык представляет строки с 0, означающим конец строки. Таким образом, в С нет счётчика длины строки. Вместо этого он учитывает все байты, и конец строки для него – это просто нулевой байт. В конце строки С пишет его обратным слэшем – «\», то есть это выглядит как amazon.com\0.

Всё это находится в памяти вашего браузера. Где-то в его памяти теперь имеется строка из 11 байт с нулём в конце. И когда браузер интерпретирует эту строку, он продолжает по ней идти, пока не увидит в конце строки нулевой маркер.

Вопрос из аудитории:

— У нас имеется 0 в середине строки?

Ответ:

— Да, это так. И в этом смысле существует некий разрыв в понимании того, как браузер интерпретирует строки.

Предположим, что я владею доменом foo.com. Я могу получить сертификат на «что-угодно- foo.com». Таким образом, я могу попросить сертификат и на имя amazon.com\0x.foo.com. С точки зрения браузера это совершенно правильная строка. Это 20 байтовое имя, состоящее из 20 байтов.

Раньше было так, что вы могли обратиться в центр авторизации СА и сказать: «Эй, я владею foo.com, дайте мне сертификат на эту штуку!». И они были бы совершенно готовы сделать это, потому что amazon.com0x — это поддомен foo.com, и он полностью твой.

Но потом, когда браузер берет эту строку и загружает ее в память, он делает, то же самое, что я описал раньше — он копирует строку. amazon.com0x.foo.com и послушно добавит в завершение этой строки ещё один ноль — amazon.com\0x.foo.com\0.

Но затем, когда остальное программное обеспечение браузера начнёт интерпретировать строку в этом месте памяти, оно начнёт её читать и, увидев 0 в середине строки, скажет: «отлично, это же конец строки!» и обнулит всё, что следует в адресе после него. Так что в результате мы получим сайт Amazon.com.

Это служит примером того, как несогласованность между интерпретационной способностью языка С и способом шифрования SSL сертификатов вызвало проблему безопасности. Это было обнаружено несколько лет назад парнем по имени Мокси Марлинспайк (Moxie Marlinspike), и это довольно разумное замечание.

Такие виды ошибок шифрования весьма распространены в программном обеспечении, за исключением случаев, когда вы очень тщательно подойдёте к кодировке, используя различные способы шифрования. И всякий раз, когда возникает подобная несогласованность, ею может воспользоваться «плохой парень». Одна система считает, что это удачное имя, другая считает, что это не так. И это является хорошим способом, чтобы подтолкнуть систему к неполадкам в работе.

Последний пример отказа механизма безопасности, о котором я расскажу сегодня, это переполнение буфера. Некоторые из вас знакомы с этой проблемой по материалам курса 6.033. Остальным напомню, что представляет собой переполнение буфера. Кстати, это тема первой лабораторной работы, так что отнеситесь к этому серьёзно, потому что вашим заданием будет воспользоваться такой уязвимостью и испробовать этот вид атаки на реальном веб-сервере.

Итак, наша система представляет собой компьютер, на котором развёрнут веб-сервер. Веб-сервер – это программа, которая будет воспринимать подключения из внешнего мира, принимать запросы, которые в основном представляют собой пакеты данных, обрабатывать их, и, вероятно, совершать какие-то проверочные действия. Если это неправильный URL или если кто-то пытается получить доступ к файлам, и он не авторизован для такого доступа, веб-сервер в качестве ответного действия выдаст сообщение об ошибке. В противном случае он предоставит доступ к файлам, возможно, расположенным на жёстком диске, и отправит их пользователю в виде какой-то формы ответа.

Это наиболее распространённая схема серверов, которую вы наверняка знаете. В чём заключается её политика и каковы модели угроз?

На самом деле довольно трудно определить политику и модели угроз, используемых во многих реальных системах. Это, в свою очередь, приводит к проблемам безопасности. В глобальном смысле политика работы веб-сервера заключается в выполнении того, что задумал программист. Это немного расплывчато, но в реальности веб-сервер должен делать именно то, что делает код, и если в этом коде имеется ошибка, её нужно отыскать.

Итак, в связи с тем, что нам трудно чётко сформулировать политику веб-сервера, будем считать, что он должен делать именно то, что хотел от него программист. Модель угрозы состоит в том, что злоумышленник не имеет доступа к компьютеру, не может воспользоваться им ни удалённо, ни физически, но может отправить на него любой пакет данных, какой захочет. То есть работа сервера не ограничена определёнными видами пакетов. Честная игра заключается в том, что вы можете сформировать и отправить на сервер любой пакет. Имейте ввиду, что на практике это весьма разумная модель угроз.

И я предполагаю, что цель состоит в том, чтобы этот веб-сервер не позволял, чтобы какие-либо условные процессы происходили неправильно. Я думаю, это согласуется с тем, что хотел от него программист. Вероятно, что программист не предусмотрел вариант, чтобы какой-то запрос давал доступ к чему-либо на этом сервере.

Но вы знаете, что при написании программного обеспечения, которое является основным механизмом работы для веб-сервера, возможны ошибки. Программное обеспечение сервера – это вещь, которая принимает запросы, рассматривает их, убеждается, что они не собираются совершить ничего плохого, и если всё в порядке, посылает обратно ответ. В этом заключается механизм веб-сервера, который обеспечивает вашу политику.

В результате, если программное обеспечение сервера даёт сбой, вы оказываетесь в беде. Как вы знаете, одна из самых распространённых ошибок при написании ПО на языке С (а многие программы написаны на этом языке, и, вероятно будут ещё на нём писаться), заключается в том, что вы можете неправильно управлять распределением памяти. Как мы видели в примере с SSL-сертификатами, даже один байт может вызвать значительные изменения в условиях происходящего. Для примера мы рассмотрим небольшой упрощённый отрывок программного кода.
На этом слайде изображён такой отрывок, представляющий собой чтение запроса.

Здесь вы видите, как выглядит запрос, поступающий на сервер из сети. Но в нашей лекции воображаемый сервер будет просто читать то, что я набираю на клавиатуре своего ноутбука. И он собирается хранить это в буфере, а затем он будет разбирать это целочисленное значение и возвращать это целочисленное значение. Реальный сервер работает далеко не так, но мы используем данный пример для демонстрации того, как происходит переполнение буфера и что при этом бывает не так. Давайте посмотрим, что произойдёт, если я запущу эту программу. Я могу её здесь скомпилировать.

Вы видите, появилось сообщение: «Функция опасна и не может быть использована». И на самом деле, она показывает мне, что я где-то облажался. Через секунду мы увидим, почему компилятор нацелен на то, чтобы сказать мне подобное, и это на самом деле так. Но пока что предположим, что нас всё устраивает, и я разработчик, готовый проигнорировать данное предупреждение.

Я запускаю функцию перенаправления, предоставляю некие входные данные, и это работает. Я ввожу 1234 и получаю х = 1234, я ввожу действительно большой набор из 28 случайных чисел и получаю ответ (х = 2147483647) из 10 чисел. Как видите, это всё ещё не катастрофа.

Теперь я набираю 19 символов А и получаю х = 0. Система устроена так, что при вводе буквенных символов она выдаёт в ответ нулевое значение. Это не так уж и плохо. Но что произойдёт, если я введу огромное количество данных, типа этой серии букв А, растянувшейся на 3 строки? Система аварийно завершит работу!

Мы не очень-то этому удивлены. То есть если вы посылаете на сервер «плохой», некорректный запрос, он ничего не может послать вам в ответ. Но давайте попробуем заглянуть вовнутрь и увидеть, что происходит, и попытаемся выяснить, как можно получить пользу от этой аварийной ситуации, или, возможно, сделать что-то более интересное, то, в чём может быть заинтересован хакер.

Продолжение: Курс MIT «Безопасность компьютерных систем». Лекция 1: «Вступление: модели угроз», часть 3


Полная версия курса доступна здесь.

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Let's block ads! (Why?)

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 1: «Вступление: модели угроз», часть 1

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год


Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3

Николай Зельдович: в этом классе на наших лекциях будет присутствовать содокладчик, приглашённый профессор Джеймс Микенс из Microsoft Research. Позже он расскажет о таких темах, как Интернет-безопасность.

В этом году у нас есть 4 помощника-преподавателя, это Стивен, Уэбб, Хоган и Джеймс. Если вам понадобиться помощь, вы можете обратиться к ним в рабочие часы в течение года.

Тема этих лекций – понять, как создавать безопасные системы, почему компьютерные системы иногда бывают небезопасными и как можно исправить положение, если что-то пошло не так. Не существует никакого учебника на эту тему, поэтому вы должны пользоваться записями этих лекций, которые также выложены на нашем сайте, и вы, ребята, должны их заблаговременно читать. Имеется также ряд вопросов, на которые вы должны будете ответить в письменной форме, а также вы можете прислать свои собственные вопросы до 10-00 часов вечера перед лекционным днём. И когда вы придёте на лекцию, мы обсудим ваши ответы и вопросы и выясним, что собой представляет эта система, какие проблемы решает, когда это работает и когда это не работает, и хороши ли эти способы в других случаях.

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

На сайте у нас есть предварительное расписание лекций, оно достаточно гибкое. Если есть другие темы, представляющие для вас интерес, или есть какие-то бумажные заметки, можете присылать их нам на электронную почту, и мы постараемся учесть ваши пожелания. Так что если вы хотите услышать о чём-то больше, чем предусмотрено, просто дайте нам знать.

Точно так же, если у вас когда-нибудь возникнет вопрос или вы заметите какую-то ошибку, просто прерывайте и спрашивайте нас в любое время лекции. Безопасность во многом состоит из деталей, поэтому на них стоит обращать внимание. Я, конечно же, буду совершать ошибки, поэтому вы должны воспользоваться шансом, чтобы об этом сказать. Просто прервите доклад и спросите, так мы выясним, что идёт не так и как это исправить.

Что касается организации лекций, то их большую часть составят лабораторные работы. Первая уже размещена на сайте. Они помогут вам понять различные проблемы компьютерной безопасности и как предотвратить их появление на простом веб-сервере. Поэтому в лабораторной работе №1 вы просто возьмёте веб-сервер, который мы вам предоставим, и попробуете найти способы взломать его, используя уязвимость, связанную с переполнением буфера. Вы завладеете контролем над сайтом, просто отправив на него тщательно проработанные запросы и пакеты.
В других лабораторных работах вы будете искать способы защиты веб-сервера, искать «баги» в коде, писать «червей», которые запускаются в браузере пользователя, и изучать другие интересные виды интернет проблем.

Многих студентов удивляет, что каждая лабораторная работа (ЛР) использует свой язык программирования. Так, ЛР №1 использует С и Ассемблер, вторая ЛР использует программирование на Python, третья ещё какой-то язык, в пятой появляется JavaScript, и так далее. Это неизбежно, поэтому заранее извиняюсь, что вам придётся изучить все эти языки, если вы до сих пор их не знаете.

В некотором смысле это даже полезно, потому что таков реальный мир. Все системы сложны и состоят из различных частей. В конце концов, это будет полезно для вашего морального самоутверждения. Однако это потребует определённой подготовки, особенно если вы не видели эти языки раньше. Так что чем раньше вы начнёте их изучать, тем лучше.

В частности, ЛР№1 будет основываться на множестве тонкостей языка C и кода Ассемблер, которые мы не преподаём здесь так подробно, как в других учебных курсах. Мы попросим ассистентов преподавателей выделить пару часов на следующей неделе, чтобы провести нечто вроде учебного занятия на тему того, как выглядит программа из двоичных кодов, как их разбирать, как выяснить, что находится в стеке, и так далее.

Ещё одно новшество состоит в том, что мы с этого года делаем видеозаписи наших лекций, которые можно потом просмотреть онлайн. Мы разместим их сражу же, как только получим от видеооператоров. Кроме того, вы можете задавать вопросы онлайн с использованием портала Piazza, как делали это во время изучения других курсов.

Прежде чем мы приступим к изучению вопросов компьютерной безопасности, скажу вам одну вещь. Существуют определённые правила, которые наш институт соблюдает для доступа к сети МТИ, поэтому при проведении исследований безопасности нужно учитывать, что не всё, что вы сможете осуществить технически, является законным. В процессе этого курса вы узнаете, как можно взломать или нарушить работу системы, но это не значит, что вы можете проделывать подобное где угодно. В этой лекции размещена ссылка на правила, в которых всё это подробно описано. В общем, если вы сомневаетесь в законности того или иного шага, лучше спросите лектора или помощника преподавателя. В конце концов, это не головоломка. И не стесняйтесь задавать вопросы

Итак, что же такое безопасность? Начнем с некоторых основных вещей и рассмотрим некоторые общие примеры того, почему бывает трудно обеспечить безопасность что значит попытаться построить безопасную систему. Эти соображения не описаны на бумаге и не являются высокоинтеллектуальными рассуждениями, но всё же прояснят вам предысторию вопроса и дадут пищу для ума на тему того, как следует представлять себе безопасность систем.

В целом безопасность представляет собой пути достижения какой-то цели, возможность противостоять присутствию реального врага. Подумайте о том, что в этом случае всегда существуют «плохие парни», которые хотят убедиться, что у вас ничего не получится. Они хотят украсть ваши файлы. Они хотят удалить содержимое вашего жёсткого диска. Они хотят убедиться, что у вас ничего не работает, ваш телефон не может выйти на связь, и так далее. Так вот, безопасной является такая система, которая действительно может что-то делать независимо от того, что пытается проделать с вами плохой парень.

Круто то, что мы можем потенциально создавать системы, устойчивые к вмешательству плохих парней, атакующих, хакеров – называйте их как угодно. И мы всё ещё способны создавать компьютерные системы, способные выполнять свою работу в таких случаях.

Для облегчения понимания безопасности разобьём её на 3 части. Одна часть представляет собой принципы, которые должна приводить в исполнение ваша система, то есть её предназначение. Назовём её Policy. Собственно, это и есть та цель, которую вы должны достичь, внедряя систему безопасности.

Например, только я должен прочитать вам содержимое этого курса 6.858. Или, может быть, помощники преподавателей, или содокладчики – то есть в этом состоит наше предназначение как «системы». Однако существуют основные требования к тому, что я хочу от своей системы, как я хочу, чтобы она выполняла своё предназначение.

Например, одним из принципов, который вы должны были бы написать, связан с конфиденциальностью данных, то есть необходимо задать права доступа, чтобы материалы лекций были доступны только тем, кто имеет право читать курс 6.858. Далее можно было бы подумать о честности, то есть ввести ограничения, что только преподаватели курса 6.858 могут изменять файл оценок, или то, что только они имеют право предоставить на кафедру итоговый файл оценок.

Затем вам нужно предусмотреть такую вещь, как доступность. Например, сайт должен быть доступен даже в том случае, если плохие парни пытаются «положить» его и организовать какой-то тип DOS–атаки, «отказа в обслуживании» Denial of Service.

Итак, это характеристики системы, которые должны нас заботить. Но поскольку это безопасность, то здесь замешан плохой парень. И нам нужно понять и подумать о том, что он собирается сделать. Именно это мы обычно называем моделью угрозы, Threat model — вторая часть системы безопасности. В основном этот набор предположений о том, что собой представляет плохой парень или противник.

Важно иметь какие-то предположения о нём, потому что он вездесущ и может проникнуть повсюду одновременно, и вы будете вынуждены делать то, что он захочет, а в этом случае трудно достичь даже подобия безопасности.

Например, вы предполагаете, что хакер не знает вашего пароля, или не имеет физического доступа к вашему телефону, к вашим ключам и к вашему ноутбуку. В противном случае не удастся достигнуть в этой игре какого-то прогресса. Получается, что пока на самом деле сложно придумать, как ещё можно защититься, но я считаю, что лучше переоценить угрозу, чем недооценить её, потому что противник всегда может удивить вас с точки зрения осуществления угрозы на практике.

Наконец, для обеспечения безопасности, для достижения нашей цели в рамках сделанных предположений об угрозах, мы должны рассмотреть какой-то механизм. Mechanism – это третья часть системы безопасности. В основном это программное или аппаратное обеспечение или какая-либо часть системного дизайна, реализации и т. д., которая будет пытаться убедиться, что наша система выполняет своё предназначение до тех пор, пока поведение хакера соответствует модели угрозы. Таким образом, конечный результат заключается в том, что пока наша модель угрозы остаётся верной, нашей системе удаётся выполнять своё предназначение. Это понятно?

Однако почему это так тяжело осуществить на практике, если наш план выглядит таким простым? Вы осуществили все 3 принципа, система заработала и вам больше нечего делать. Однако на практике вы могли убедиться, что компьютерные системы всегда взламывают тем или иным способом. И взломы довольно обычное дело. Основная причина, по которой обеспечение безопасности становится проблемой, это выбор неправильной цели (об этом уже говорили в курсе 6.033), значит, мы должны убедиться, что наша политика безопасности действует независимо от того, что предпринимает злоумышленник.

Давайте пойдём от обратного. Если вы хотите построить файловую систему и убедиться, что мои помощники могут получить доступ к файлу оценок, это довольно легко. Я просто спрашиваю его: «Эй, ребята, сходите и посмотрите, можете ли вы получить доступ к оценкам?», и если им это удаётся, то прекрасно, работа сделана, система работает.

Но если мне надо, чтобы никто, кроме моих помощников, не имел доступа к файлу оценок, то осуществление подобного принципа представит собой более серьёзную проблему. Потому что теперь я должен выяснить, что могут проделать все те люди, которые не являются моими ассистентами, для того, чтобы получить файл оценок. Они могут просто попытаться открыть его и прочитать, и возможно, что моя система безопасности должна это запретить.

Но они могут попробовать другие виды атак, например, подбор пароля моего ассистента, или кражу его ноутбука, или взлом его комнаты, кто знает?

Все эти способы взлома должны учитываться нашей моделью угроз. Например, я не беспокоюсь о файле оценок в случае, если из общежития украдут ваш ноутбук. Хотя, возможно, должен бы был и этим озаботиться, трудно сказать. В результате эти игры с безопасностью не настолько ясно представляются, чтобы изначально составить правильные предположения о возможных угрозах. Иногда бывает так, что только после их осуществления вы задумываетесь, что хорошо бы было предусмотреть такой способ взлома заранее.

Поэтому, как следствие, это очень итеративный процесс. И только после того, как вы реализуете каждую итерацию, вы сможете увидеть, где самое слабое звено вашей системы. Может быть, я не правильно составил модель угрозы. Может быть, мой механизм содержал некоторые ошибки, поскольку это программное обеспечение для использования в больших системах, а в них обычно содержится множество «багов».

И вы начинаете править ошибки, менять модель угрозы, переделывать всю систему безопасности, и к счастью, делаете её лучшей.

Одно из опасных пониманий темы этих занятий состоит в том, что вы просто уйдёте с мыслью о том, что всё кругом взломано, ничего не работает, мы должны просто сложить руки и прекратить пользоваться компьютерами. Это одна из возможных интерпретаций проблемы, но она не совсем правильна. Тема этих лекций заключается в том, что мы рассмотрим все эти различные системы, чтобы продвинуться в их понимании.

Мы должны рассмотреть, что произойдёт, если сделать вот так? Оно сломается? А что получится, если попробовать сделать это? К чему оно приведёт? Неизбежно, что каждая система будет иметь свою точку взлома, и мы разберёмся в своих проблемах, когда её обнаружим. Мы поймём, что можем взломать эту систему, если пойдём таким путём, или что система перестанет работать при таком наборе условий.

Каждая система неизбежно будет иметь своё уязвимое место, но это совсем не означает, что все компьютерные системы никчёмны и беззащитны. Это просто означает, что вы должны знать, где и какой дизайн системы нужно использовать. И упражнения по поиску уязвимых точек помогут узнать, в каких случаях данные способы срабатывают, а в каких нет.

В реальности это имеет нечёткие границы, но чем более безопасной вы делаете свою систему, тем меньше вероятность того, что попадёте в историю на первой странице New York Times, рассказывающую о том, как номера социального страхования миллионов людей попали в открытый доступ. И при этом вы платите меньше денег, чтобы защититься от подобной ситуации. Одна из выдающихся черт безопасности заключается в том, что она способна проделать такие вещи, которые вы не могли предусмотреть заранее, потому что механизмы безопасности, предусматривающие возможность защиты от определённых типов угроз, являются чрезвычайно мощными.

Например, браузер раньше был довольно скучной вещью в смысле того, что с ним можно проделать. Вы могли только просматривать в нём веб-страницы или запускать какие-нибудь JavaScript. Но сейчас это довольно крутые механизмы, которые мы изучали несколько недель назад, и которые позволяют вам запускать произвольный код х86 и убеждаться, что он не может сделать ничего «весёлого» с вашим компьютером. Существует интересная технология Native Client от Google, это «песочница», позволяющая безопасно запускать машинный код прямо в браузере, не зависимо от операционной системы.

Прежде, чем запустить какую-то игру на вашей машине, вы должны загрузить её и установить, а для этого необходимо отметить в диалоговом окне, что вы разрешаете ей совершить ряд действий. Но сейчас вы просто можете запустить её в браузере, без всяких дополнительных кликов, и она пойдёт. Причина, по которой это так просто и мощно, состоит в том, что система безопасности запускает программу в изолированной «песочнице», не предлагая пользователю ничего решать относительно безопасности или вредоносности данной игры или любой другой программы, запускаемой на компьютере. В большинстве случаев хороший механизм безопасности позволяет конструировать такие крутые новые системы, которые до этого невозможно было создать.

Поэтому в остальной части нашей лекции я хочу привести вам ряд примеров, когда система безопасности работает неправильно. Эти примеры научат вас, как не надо поступать, чтобы у вас сформировалось лучшее представление о том, как требуется подходить к решению проблем безопасности. В этом случае взлом системы безопасности показывает, что практически каждая из 3-х составляющих её частей была сделана неправильно. На практике люди ошибаются и в функциях системы, и в создании модели угрозы, и в механизме реализации защитных функций.

Давайте начнём с примеров того, как можно испортить системную политику, то есть предназначение системы. Возможно, самый ясный для понимания и простой пример это запрос на восстановление доступа к учётной записи. Как известно, при входе в учётную запись на сайте вы вводите пароль. Но что произойдёт, если вы его потеряете? Некоторые сайты пришлют вам пароль на электронную почту, если вы потеряли свой пароль, со ссылкой на страницу изменения пароля. Так что это достаточно просто, если вы указали резервный почтовый ящик. В этом заключалась система безопасности, предложенная вашим провайдером электронной почты.

Ещё несколько лет назад Yahoo создали свою электронную почту в Интернете, где использовали другой механизм восстановления пароля. Если вы забыли свой пароль от ящика Yahoo, они не могли его вам никуда прислать, потому что вариант использования запасного почтового ящика не предусматривался. Вместо этого для восстановления пароля вы должны были ответить на пару вопросов, ответы на которые могли знать только вы. И если вы забыли пароль от своего ящика, то могли нажать на ссылку, ответить на вопросы и получить свой пароль снова.

Что произошло в этом случае? Изменение политики безопасности, потому что прежде политика состояла в том, что воспользоваться ящиком электронной почты можно было только в случае, если вы знали пароль. Теперь же воспользоваться входом могли не только люди, знающие пароль, но и те, кто знал ответы на вопросы. И это прямым образом ухудшило безопасность системы, чем и воспользовались некоторые люди.

Одним из хорошо известных примеров является случай с Сарой Пэйлин, у которой был ящик на Yahoo. Её секретными вопросами были такие, как: «Где вы посещали школу? Как звали вашего друга? Когда у вас день рождения?» и так далее. Всё это было написано на её странице в Википедии. И в результате этого любой мог зайти в её электронную почту Yahoo, просто прочитав в Википедии, в какую школу она ходила и когда родилась. Так что вам действительно нужно тщательно обдумать последствия различных политик безопасности, прежде чем внедрять их в жизнь.

Более сложным и интересным примером является то, что происходит, когда у вас есть несколько систем, которые начинают взаимодействовать друг с другом. Есть хорошая история о парне по имени Мэт Хонан, возможно, вы её прочитали пару лет назад. Он является редактором журнала wired.com. Так вот, кто-то завладел его почтой на Gmail и сделал много плохих вещей. Нас интересует, как ему это удалось? Это довольно интересно, потому что обе стороны этой истории делали вроде бы разумные вещи, однако это привело к печальным результатам.

Итак, у нас есть Gmail, который позволяет восстановить забытый пароль, как это делают почти все остальные почтовые сервисы. Для того, чтобы изменить пароль от ящика Gmail, вы отправляете им запрос. Однако они не ответят, если запрос поступил от какого-то незнакомца, они пошлют вам ссылку для восстановления пароля на резервный адрес электронной почты или адрес другой электронной почты, который вы указали при регистрации. Полезно то, что они обычно распечатывают для вас адрес электронной почты. Так что если кто-то зайдёт от имени нашего парня и попросит дать ссылку на переустановку пароля, они ответят: «конечно, без проблем, мы вышлем её на ваш запасной ящик foo@me.com, который является службой электронной почты Apple».

Отлично, но у плохого парня нет доступа к ящику на @me.com. Однако он хочет получить эту ссылку, чтобы затем получить доступ к ящику на Gmail. Оказывается, что в случае с почтовым сервисом Apple имеется возможность изменить пароль от ящика @me.com, если указать ваш платежный адрес и последние четыре цифры номера вашей кредитной карты. Нам всё ещё не понятно, как злоумышленнику удалось решить эту задачу. Допустим, он мог узнать домашний адрес Мэта, в своё время тот был довольно известным человеком, но как хакеру удалось завладеть номером кредитной карты Хонана? Продолжим нашу историю.

Оказывается, у этого парня был аккаунт на Amazon.com, который выступал другой частью этой истории. Amazon действительно заинтересован в том, чтобы вы покупали вещи. Поэтому он имеют достаточно хитроумную систему управления аккаунтом. Но так как прежде всего Amazon заинтересован в вас как в покупателе, он не требует регистрации на сайте, если вы собираетесь купить какую-то вещь и оплатить её с помощью кредитной карты.

Так что я могу зайти на Amazon.com и сказать, что я именно этот пользователь и хочу приобрести этот набор зубных щёток. И если я хочу использовать сохранённый в аккаунте номер кредитной карты, я должен войти в этот аккаунт. И если я хочу добавить к этому аккаунту другую карту, «Амазон» предоставляет мне такую возможность. Это выглядит неплохо, не так ли? Я могу оплатить набор щеток, используя один из двух аккаунтов, но это всё равно номера не вашей кредитной карты, а моей. Так что нам всё ещё не понятно, что в этом деле происходит не так.
Но у Amazon есть и другой интерфейс, ведь это сложные системы, поэтому у него имеется интерфейс для сброса пароля. Для того, чтобы сбросить пароль в Amazon, вам необходимо предоставить номер любой одной из ваших кредитных карт. Что же у меня получается?
Я могу заказать вещи и добавить номер кредитной карты на свой аккаунт, который на самом деле принадлежит не мне, а затем сказать: «Эй, ребята, я хочу изменить свой пароль, вот вам номер моей кредитной карты!». И это сработало – именно так хакер получил доступ к аккаунту своей жертвы на Amazon.com.

Отлично, но как ему удалось раздобыть номер кредитной карты для смены пароля электронной почты Apple? Amazon в этом смысле очень осторожен. Даже если вам удастся войти в чей-то аккаунт, вы не увидите полного номера кредитной карты. Но вам покажут его последние 4 цифры, просто чтобы вы знали, какой картой пользуетесь в данный момент. Таким образом, вы можете переписать последние 4 цифры номера всех кредитных карт данного аккаунта кроме той, которую сами добавили – её номер вы и так знаете. После этого вы сможете войти в ящик жертвы на @me.com, получить там ссылку на сброс пароля и завладеть ящиком Gmail.

Это достаточно деликатные вещи. Если система изолирована, она делает разумные вещи. Намного трудней рассуждать об уязвимости и слабых сторонах, когда от вас скрыта вся мозаика, и вы вынуждены собирать её вместе по кусочкам. Это довольно сложная штука. Поэтому к созданию каждой из 3-х частей, составляющих систему безопасности, нужно подходить очень внимательно и вдумчиво.

Я думаю, что генеральный план заключается в том, чтобы быть осторожным при выборе своей политики, чтобы не зависеть от влияния других сайтов. Я не уверен, что есть какой-то действительно хороший совет, как поступать в таких случаях. Но теперь вы об этом знаете и можете совершать другие ошибки. Есть множество других примеров неправильно выбранных политик, приводящих к уязвимости системы.

Давайте рассмотрим, как люди создают модели угроз, и что собой представляют примеры, когда модель угроз приводит к неприятностям.

В большинстве своём это связано с человеческим фактором. Мы часто предполагаем, что люди будут поступать по нашим правилам, придумают надёжный пароль, не станут переходить по ссылкам на чужие сайты и вводить пароль там, и так далее. Однако на практике получается не так. Люди будут придумывать плохие пароли, переходить по ссылкам и не будут обращать внимания на ваши предупреждения.

То есть, вероятно, вы не захотите иметь модели угроз, основанные на предположениях, что люди неизбежно будут делать так, чтобы всё пошло неправильно.

Ещё одной чертой моделей угроз является то, что они меняются со временем. Примером может служить проект «Афина» созданный в нашем институте в середине 80-х годов, в результате которого была разработана система «Цербер». Вы узнаете о нём на лекциях через пару недель. Разработчики выяснили, что «Цербер» должен основываться на криптографии. Поэтому требовалось создать такие шифровальные ключи, чтобы люди не могли их разгадать. В то время 56 битные ключи казались вполне подходящего размера для шифра DES (Data Encryption Standard). Для середины 80-х это было нормально.

Вы знаете, что позже эта система стала весьма популярной и MIT использует её до сих пор. И её создатели никогда не возвращались к пересмотру данного предположения. А затем, несколько лет назад группа студентов курса 6.858 выяснила, что «Цербер» достаточно просто взломать. На сегодня очень легко с помощью компьютера подобрать все ключи простым перебором значения 256. В результате эти ребята смогли с помощью аппаратного обеспечения определённого веб-сервиса (у вас будут ссылки на него в лекционном материале) смогли получить ключ от аккаунта «Цербера» за один день. Так что модель, которая была хороша в середине 80-х, на сегодня является не настолько хорошей. Поэтому при разработке модели угроз вы должны быть уверены, что идёте в ногу со временем.

Возможно, более современным примером станет пример, когда вашим противником могут стать правительственные организации, использующие специально разработанное «железо», которому вы не должны доверять. В особенности это касается АНБ – вы наверняка знакомы с «откровениями» на тему того, на что способны эти парни. У них имеются специальные «жучки», которые они могут вставить в ваш компьютер. Ещё каких-то пару лет назад мы об этом не знали, поэтому разумно звучало предположение о том, что ваш ноутбук не может быть уязвим физически, так как невозможно скомпрометировать само «железо».

25:30 мин

Продолжение: Курс MIT «Безопасность компьютерных систем». Лекция 1: «Вступление: модели угроз», часть 2


Полная версия курса доступна здесь.

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Let's block ads! (Why?)

[Из песочницы] Метод фрактального многообразия в задачах Data Science

1. Постановка задачи


Наборы числовых упорядоченных данных можно разделить на две группы: гауссовы и странные (негауссовы). Если к гауссовым данным можно применять количественное сравнение, то к странным данным такой подход неприменим ввиду их относительности и отсутствия стандарта, что оставляет возможным лишь качественный анализ, который во многих случаях является неоднозначным и трудоемким. При этом такие данные широко распространены, а задача их анализа является актуальной для многих областей науки.

Далее будет представлен вычислительный метод, преобразующий исходные негауссовы данные в гауссовы, что позволяет в дальнейшем сравнивать количественно структурные характеристики больших наборов данных.

Преобразованное значение негауссовых данных, допускающее количественное сравнение, должно быть инвариантно относительно любых линейных преобразований значений исходных данных, нечисловая статистика [1]. Задача имеет решение только для упорядоченных странных данных и с учётом окрестности, в которой проявляется нелинейность.

2. Вычислительный метод


Преобразованное значение негауссовых данных, допускающее количественное сравнение, должно быть инвариантно относительно любых линейных преобразований значений исходных данных [1]. Задача имеет решение только для упорядоченных странных данных и с учётом окрестности, в которой проявляется нелинейность. Как показано в работе, преобразование должно обладать ренормгрупповой инвариантностью в отношении размера окрестности, в которой происходит количественное сравнение проявлений нелинейности.

Далее приводятся ключевые шаги вывода формулы отношения сигнала к шуму, допускающего количественное сравнение. Фрактал пыль Кантора или геометрическая прогрессия с произвольным значением 0
Предлагается следующий способ построения фрактального многообразия. Фрактальное многообразие для n=5 произвольного набора пяти упорядоченных чисел имеет вид:

С каждым фрактальным циклом m, где m→∞, появляется новое число из выборки негауссовых данных n и далее по замкнутому контуру. Различается левое и правое направление обхода контура. В общем виде:

Аналогично для получается:

Здесь и далее формулы в обозначении Mathcad.

Множества и образуют фрактальные многообразия. Определяется выражение для отношения сигнала к шуму:

Уникальность функций Гаусса, Бесселя состоит в том, что отношение сигнала к шуму SNR в определении (5) не зависит от значения n. При аппроксимации данных функциями Бесселя коллективный эффект не проявляется.

При моделировании негауссовых данных полуволной , что применяется в расчётах с предварительной аппроксимацией данных конечным рядом Фурье, для достаточно больших значений n выражение отношения сигнала к шуму имеет вид:

Потребуем выполнение условия ренормгрупповой инвариантности SNR(n,q), приближающее странные данные к гауссовым: при изменении n→n' происходит преобразование q→q', оставляющее значение SNR(n,q) (8) неизменным в методе ренормализационной группы [2]. Требование ренормгрупповой инвариантности выполняется при условии:

Решение дифференциального уравнения имеет вид:

Выбор постоянной величины μ задаёт масштаб отношения сигнала к шуму.

Для больших значений n, асимптотики параметров длины фрактальных многообразий и в модели полуволны , с учётом ренормгруппового уравнения для q(n) (10) имеют вид:

Хаусдорфова фрактальная размерность по Колмогорову [3] для фрактальных многообразий, построенных с учётом направления обхода замкнутого контура из n чисел:

Среднее как для гауссовых чисел:

отличается от среднего по Колмогорову для D=2/3

В качестве иллюстрации метода фрактального многообразия приводятся вычисления для биномиальных коэффициентов, близких к гауссову множеству, нормированных на асимптотику:

Для достаточно больших значений n выражение отношения сигнала к шуму имеет вид:

Ренормгрупповое уравнение для q(n):

Фрактальная размерность для нормированных биномиальных коэффициентов D=4/5.

Выбор среднего для негауссовых данных как для гауссовых чисел часто применяемый в расчётах, не является однозначным [1]. Не только само значение среднего, но и вид формулы для вычисления среднего значения определяется странными данными. Метод фрактального многообразия позволяет точнее определить такую известную характеристику структуры как среднее значение, используя в качестве инструмента более мелкий масштаб , по сравнению с евклидовым масштабом и выявить качественно новую структурную характеристику – степень взаимной корреляции данных или степень коллективного состояния данных, определяемой SNR.

Таким образом, появление зависимости SNR от числа выборки n для негауссовых данных объясняется наличием взаимной корреляцией негауссовых данных. Внедрение параметра q фрактала пыль Кантора и применение метода ренормгрупповой инвариантности в отношении SNR позволяет перейти к традиционному анализу гауссовых данных – степени корреляции данных в определении SNR(5).

Проводятся предварительные вычисления при q=0 по формулам (24)-(26). На предварительном этапе расчётов, при сравнении различных наборов упорядоченных данных, получаются критические размеры дескрипторов n(кр1), n(кр2) обеспечивающие максимальные коллективные состояния в наборах данных. Тогда принимается значение -3 в формуле (10) и уточняется значение с учётом ренормгрупповой инвариантности (20)-(23). Сравнение значений SNR разных наборов данных является корректным при вычислении, выполненном в одном масштабе μ. Пиковые значения характеризуют наличие структуры в данных переменной x, обозначают окрестность коллективного состояния. Понятие критического или коллективного состояния характерно в подходе странной кинетики, обозначая кластер степеней свободы с сильной корреляцией. Поведение системы в окрестности коллективного состояния носит универсальный характер и не зависит от природы взаимодействия, вызывающего корреляцию [5], как и универсальность распределения случайных величин в отсутствии взаимной корреляции.

Параметры аппроксимации конечного ряда Фурье и размер дескриптора n при прохождении упорядоченных данных с единичным шагом определяются из условия максимума целевой функции – максимального коллективного состояния в системе.

В матричном виде ренорм-инвариантные формулы для отношения сигнала к шуму имеют вид:

где

Результаты вычислений по формулам (11)-(14) эквивалентны результатам исходных вычислений по формулам (3)-(5), при этом позволяют составление алгоритма.
В расчётах из K=n/2+1 уникальных упорядоченных данных спектра строится симметричный вектор:

Для достаточно больших K, когда выполняется условие ренормгрупповой инвариантности, и q=0, с учётом симметрии матриц S и N, формулы для отношения сигнала к шуму приобретают вид:

При сопоставлении значений SNR со шкалой упорядочивания, шкала сдвигается влево на размер дескриптора K. Упорядоченный набор данных, с предварительной аппроксимацией конечным рядом Фурье k, проходят дескриптором, размером K, с единичным шагом. Вычисляется по проходу всех точек в наборе данных. Целевая функция определяется как при переборе параметров K и k. Как уже отмечалось, корректное сравнение структурных характеристик SNR разных наборов данных должно осуществляться в едином масштабе μ с учётом ренормгрупповой инвариантности((20)-(23)). Подобно сравнению измерений, выполненных в сантиметрах и дюймах.

Вычислительный метод применяется для больших наборов данных, полученных в хорошем разрешении, что позволяет увеличить масштаб сравнения μ с сохранением ренормгрупповой инвариантности. По порядку величин, в задаче с конформерами общее число данных в спектре рентгеноструктурного анализа – 2250 значений, оптимальный размер дескриптора для данного разрешения K=585, максимальная гармоника конечного ряда Фурье k=3.

3. Выводы


Метод применим в определении областей с сильной корреляцией степеней свободы между собой и количественном сравнении степени корреляции больших наборов упорядоченных данных. Например, когда неприменимо приближение Хартри-Фока. Интерпретация результатов обработки данных основана на построении фрактального многообразия, которое моделирует коллективное или критическое состояние [4] в одномерном пространстве. Интерпретацию усложняет неоднозначность терминологии, описывающей коллективное состояние в разных задачах.

Коллективным состоянием в химии называют гибкость или подвижность молекулярных фрагментов. Гипотеза Кошланда индуцированного соответствия при проявлении биологической активности, основанная на допущении гибкости активного центра фермента, удовлетворительно объясняет действие ферментов. При приближении субстрата к активному центру фермента, в молекуле фермента синхронно происходит конформационная перестройка, затрагивающая большое число степеней свободы. Применение вычислительного метода к спектру трёх конформеров показывает значительное увеличение коллективного эффекта у конформера, отличающегося биологической активностью. Аналогичный, с проявлением биологической активности, пример коллективного эффекта проявляется в методе термомеханической кривой для полимеров с разной молекулярной массой в области высокой эластичности.

Применение универсальной формулы преобразования к большим наборам негауссовых данным с учётом свойств инвариантности относительно любых линейных преобразований и ренормгрупповой инвариантности, делает возможным количественное сравнение коллективных состояний. Метод применяется при решении задач data science в предварительном преобразовании исходных негауссовых данных и сравнении степени взаимной корреляции данных и в поиске количественных соотношений структура – свойство.

4. Литература


  1. Орлов А.И. Прикладная статистика. — М.: Экзамен, 2006. — 574 с
  2. Боголюбов Н. Н., Ширков Д. В. Введение в теорию квантованных полей. — 4-е изд., испр. — М.: Наука Главной редакции физико-математической литературы, 1984. — 600 с.
  3. Колмогоров А.Н., Новый метрический инвариант транзитивных динамических систем и автоморфизмов пространств Лебега, — 1958, Доклады АН СССР, №5, С. 861 — 864
  4. Зелёный Л.М., Милованов А.В. Успехи физических наук, Фрактальная топология и странная кинетика: от теории перколяции к проблемам космической электродинамики, — 2004, №8, С.809 – 852

Let's block ads! (Why?)