tgoop.com/computersecuritybasics/60
Last Update:
Ключевые моменты лекции 5 /
Принципы безопасности
До сих пор мы уделяли много внимания методическому подходу, но не говорили про эвристики. А это важно, учитывая, что чаще всего методы – это переработанные и формализованные lessons learned, то есть те самые эвристики.
В компьютерной безопасности выделяют 8 основных эвристик (иногда больше, иногда меньше), именно эти эвристики были сформулированы почти 50 лет назад Зальцером и Шредером, до сих пор они не утратили актуальность.
Это:
✔️Принцип простоты (Economy of mechanism): механизм должен быть настолько простым, насколько это возможно.
Важно не обманываться: системы систем могут казаться простыми, их скрытая сложность может либо быть спрятана в их сложных элементах, либо быть эмерджентной, то есть проявляться при взаимодействии элементов. Приведем в пример MILS: достаточно ясная модель архитектуры может включать в себя достаточно сложную реализацию отдельных доменов. Но, помимо этого, организация взаимодействия доменов на прикладном уровне влечет эмерджентную сложность. Ядро разделения превращает отдельный хост фактически в распределенную систему (сеть), а значит, поверх простых IPC между узлами этой системы нам потребуется стек протоколов. Это не обязательно TCP/IP – это может быть RPC фреймворк, которые как известно, всегда достаточно сложны (на заре MILS были исследования, можно ли успешно совместить ее, например, с CORBA). Это проблема, и она требует хорошего инженерного решения через декомпозицию и дальнейшее упрощение.
✔️Принцип безопасных умолчаний (Fail-safe defaults): решения о доступе должны приниматься на основе явных разрешений, а не на основе запретов.
✔️Принцип полноты перекрытия (complete mediation): каждый доступ к каждому контролируемому объекту должен проверяться. Применяется как «в пространстве», так и «во времени». Здесь можно напомнить про полноту спецификаций (верификация требований) и адекватность системы ее спецификации (валидация системы относительно верифицированных требований).
✔️Принцип открытого дизайна (open design): безопасность системы не должна базироваться на сокрытии деталей ее реализации. Можно сформулировать по-другому: раскрытие любых деталей реализации, кроме ключей и паролей, не должно влиять на степень безопасности системы.
Это работает в любую сторону: вопреки распространенному мнению, раскрытие деталей реализации в том числе через опенсорс не повышает безопасность системы или кода. Раскрытие кода может повышать доверие, но только в том случае, если способы контрибьютить в код контролируются (инициативы типа прозрачности).
✔️Принцип разделения привилегий (Separation of privilege) или разделения обязанностей: где возможно, принятие решения о доступе или о выполнении операции должно базироваться на двух факторах доверия вместо одного. Это могут быть два пользователя, независимо подтверждающие операцию, либо другие факторы, имеющие независимые факторы доверия.
Вопрос – больше независимых факторов – больше доверия? В целом да, но трудно реализовать много независимых факторов и раздельных каналов связи для доставки информации о них для авторизации.
✔️Принцип наименьших привилегий (Least privilege): каждый процесс или пользователь должен обладать наименьшими привилегиями для выполнения рабочих обязанностей. Иногда проблемой является недостаточная гранулярность привилегий и прав для выполнения принципа.
✔️Принцип наименьших разделяемых механизмов (Least common mechanism): следует минимизировать механизмы, от работы которых зависит один пользователь и работа которых определяется другими пользователями. Тут речь идет о снижении зависимостей и взаимного влияния, т.е. о том, что системы должны быть слабосвязанными.
✔️Принцип психологической приемлемости (psychological acceptability): Механизм безопасности не должен провоцировать собственное отключение (а в идеале, должен быть спроектирован так, чтобы «подталкивать» пользователя использовать его).
BY Computer security basics
Share with your friend now:
tgoop.com/computersecuritybasics/60