Computer security basics

Что же касается «separation of functions», то часто этот термин встречается как прямой синоним SoD или разделения привилегий. Но вот это уже я совсем не считаю правильным, как минимум в контексте ИБ. Во-первых, это терминологически неаккуратно: separation of functions, как и separation of tasks относится к любым функциям (задачам), не только к требующим каких-то особенных привилегий. А значит их точно так же можно отнести к необходимости, например, функционального деления ПО на модули, например так, чтобы каждому пользователю были сопоставлены только необходимые функции (задачи). А это уже реализация принципа минимальных привилегий. Выходит путаница.

Я знаю только про одно «официальное» использование принципов разделения обязанностей и разделения функций: в рамках модели Липнера, описывающей разработку ПО. Вот так их описание дается в книжке Мэтта Бишопа:
«Принцип разделения обязанностей гласит, что, если для выполнения критической функции требуется два или более шагов, эти шаги должны выполнять как минимум два разных человека. Перемещение программы из системы разработки в продакшн является примером критической функции. Предположим, что один из разработчиков приложений сделал неверное предположение при разработке программы. Часть процедуры установки заключается в том, чтобы установщик удостоверил, что программа работает «правильно», то есть в соответствии с требованиями. Ошибка с большей вероятностью будет обнаружена, если установщиком является другой человек (или группа людей), а не разработчик. Точно так же, если разработчик хочет испортить данные в продакшн, внедрив трояна, то либо установщик, проверяющий корректность работы, не должен обнаружить троянский код, либо он должен быть в сговоре с разработчиком. (примечание – это снижает вероятность успеха атаки)
Разделение функций определяется так: один человек не должен иметь возможность выполнять разные задачи (роли) в рамках одной критической функции. Разработчики не разрабатывают новые программы в продакшн окружении из-за потенциальной угрозы реальным рабочим данным. Точно так же разработчики не обрабатывают реальные данные в окружении разработки во избежание утечки этих данных. В зависимости от конфиденциальности данных разработчики и тестировщики могут получать очищенные (sanitized) реальные данные. Кроме того, среда разработки должна быть максимально похожа на продакшн».

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

👍4

www.tgoop.com/computersecuritybasics/71

772 viewsMay 11, 2022 at 18:22

Что же касается «separation of functions», то часто этот термин встречается как прямой синоним SoD или разделения привилегий. Но вот это уже я совсем не считаю правильным, как минимум в контексте ИБ. Во-первых, это терминологически неаккуратно: separation of functions, как и separation of tasks относится к любым функциям (задачам), не только к требующим каких-то особенных привилегий. А значит их точно так же можно отнести к необходимости, например, функционального деления ПО на модули, например так, чтобы каждому пользователю были сопоставлены только необходимые функции (задачи). А это уже реализация принципа минимальных привилегий. Выходит путаница.

Я знаю только про одно «официальное» использование принципов разделения обязанностей и разделения функций: в рамках модели Липнера, описывающей разработку ПО. Вот так их описание дается в книжке Мэтта Бишопа:
«Принцип разделения обязанностей гласит, что, если для выполнения критической функции требуется два или более шагов, эти шаги должны выполнять как минимум два разных человека. Перемещение программы из системы разработки в продакшн является примером критической функции. Предположим, что один из разработчиков приложений сделал неверное предположение при разработке программы. Часть процедуры установки заключается в том, чтобы установщик удостоверил, что программа работает «правильно», то есть в соответствии с требованиями. Ошибка с большей вероятностью будет обнаружена, если установщиком является другой человек (или группа людей), а не разработчик. Точно так же, если разработчик хочет испортить данные в продакшн, внедрив трояна, то либо установщик, проверяющий корректность работы, не должен обнаружить троянский код, либо он должен быть в сговоре с разработчиком. (примечание – это снижает вероятность успеха атаки)
Разделение функций определяется так: один человек не должен иметь возможность выполнять разные задачи (роли) в рамках одной критической функции. Разработчики не разрабатывают новые программы в продакшн окружении из-за потенциальной угрозы реальным рабочим данным. Точно так же разработчики не обрабатывают реальные данные в окружении разработки во избежание утечки этих данных. В зависимости от конфиденциальности данных разработчики и тестировщики могут получать очищенные (sanitized) реальные данные. Кроме того, среда разработки должна быть максимально похожа на продакшн».

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

BY Computer security basics