ПРИНЦИП ОЧЕРЕДНОЙ ПРИВИЛЕГИИ
«Принцип наименьших привилегий. Каждая программа и каждый привилегированный пользователь системы должны работать с использованием минимального количества привилегий, необходимых для выполнения задания. Цель этого принципа состоит в том, чтобы уменьшить количество потенциальных взаимодействий между привилегированными программами до минимума, необходимого для правильной работы, чтобы можно было развить уверенность в том, что непреднамеренного, нежелательного или ненадлежащего использования привилегий не произойдет». - Джером Х. Солтцер , описывающий принцип проектирования операционной системы Multics в 1974 году:
https://pdfs.semanticscholar.org/ 1c8d / 06510ad449ad24fbdd164f8008cc730cab47.pdf.
Например, код может проверять конкретный идентификатор пользователя или пароль и может обойти обычные процедуры безопасности при получении этого идентификатора или пароля. Программисты использовали метод «ловушки» для хищения из банков путем включения ошибок округления в их код и получения случайных полцентов, зачисляемых на их учетные записи. Эта учетная запись может увеличивать сумму денег, учитывая количество транзакций, выполняемых крупным банком. Дверь ловушки может быть настроена на работу только в определенном наборе логических условий, в которых случай относится к подобной бомбе. Задние двери этого типа особенно трудно обнаружить, поскольку они могут оставаться неактивными в течение длительного времени, возможно, годы, прежде чем быть обнаруженным - обычно после того, как ущерб был нанесен. Например, один сетевой администратор имел деструктивную реконфигурацию сети своей компании, когда обнаружил, что его программа не работает больше в компании. Умный люк может быть включен в компилятор. Компилятор может генерировать стандартный объектный код, а также люк независимо от того, какой исходный код компилируется. Это занятие особенно гнусно, так как поиск исходного кода программы не выявит никаких проблем. Только обратный инжиниринг кода компиляции сам по себе может быть полезен для этой программы. Этот тип может быть выполнен путем исправления библиотек времени компиляции после свершившегося факта. Действительно, в 2015 году вредоносное ПО, предназначенное для набора компиляторов Apple XCode (получившее название «XCodeGhost»), затронуло многих разработчиков программного обеспечения, которые использовали скомпрометированные версии XCode, которые не загружались непосредственно из Apple. Ловушки представляют собой сложную проблему, потому что, чтобы обнаружить их, мы должны проанализировать весь исходный код для всех компонентов системы. Учитывая, что программные системы могут состоять из миллионов строк кода, этот анализ проводится не часто, а часто вообще не делается! Методология разработки программного обеспечения, которая может помочь устранить этот тип дыры в безопасности, - это проверка кода. В обзоре кода разработчик, написавший код, передает его в базу кода, а один или несколько разработчиков проверяют код и утверждают его или предоставляют комментарии. После того как определенный набор проверяющих одобрит код (иногда после того, как комментарии будут рассмотрены, а код повторно отправлен и повторно проверен), код будет принят в базу кода, а затем скомпилирован, отлажен и, наконец, выпущен для использования. Многие хорошие разработчики программного обеспечения используют системы контроля версий, которые предоставляют инструменты для проверки кода, например, git (https://github.com/git/). Также обратите внимание, что существуют инструменты автоматического анализа кода и сканирования кода, предназначенные для поиска недостатков, в том числе недостатков безопасности, но, как правило, хорошие программисты являются лучшими рецензентами кода. Для тех, кто не занимается разработкой кода, проверка кода полезна для поиска и сообщения о недостатках (или для их обнаружения и использования). Для большинства разработчиков программного обеспечения исходный код недоступен, что делает проверку кода гораздо сложнее для разработчиков.
Достарыңызбен бөлісу: |