что такое принцип минимизации программного обеспечения
Принцип наименьших привилегий: основы и лучшие практики
Один из наиболее важных принципов при реализации комплекса мер в сфере безопасности – принцип наименьших привилегий.
Один из наиболее важных принципов при реализации комплекса мер в сфере безопасности – принцип наименьших привилегий. В этой статье мы рассмотрим суть данной идеи, и как эта модель может повысить ваш уровень безопасности.
Суть принципа наименьших привилегий
Принцип наименьших привилегий основан на идее, что у каждого пользователя должен быть доступ только к ресурсам, необходимым для выполнения требуемых обязанностей. Например, у менеджера по продажам не должно быть доступа к финансовым отчетам, а аккаунт сотрудника, занимающегося маркировкой, не должен иметь административных привилегий.
Преимущества модели наименьших привилегий
Организация может получить много преимуществ от внедрения принца наименьших привилегий среди своих сотрудников. Компания, которая успешно внедрила эту модель, создает среду, где у пользователей есть доступ только к самым нужным ресурсам, что, помимо всего прочего, влияет на повышение эффективности и производительности.
Среди других преимуществ можно выделить следующие:
Повышение безопасности: когда привилегии раздаются строго в рамках сферы ответственности, значительно сокращается риск ущерба от многих потенциальных внутренних угроз.
Снижение вероятности атак, связанных с «горизонтальным» движением по инфраструктуре: переизбыток привилегированных аккаунтов дает много возможностей для атак, связанных с горизонтальным перемещением по инфраструктуре (lateral movement attack).
Защита от других угроз: принцип наименьших привилегий помогает предотвратить и другие распространенные угрозы, в частности, связанные с вредоносными программами.
Безопасная сеть: в хорошо организованной и безопасной сети в обязанности администратора входит аудит прав доступа всех пользователей. Принцип «все для всех» быстро приведет к хаосу.
Пример практик в сфере безопасности, связанных с принципом наименьших привилегий
Ниже продемонстрировано два примера, как в организации может быть использован принцип наименьших привилегий.
Аккаунты с наименьшими необходимыми привилегиями
Идея о назначении только нужных прав доступа кажется очевидной, но является одной из самых эффективных и недооцененных для снижения риска многих угроз. Например, снижается вероятность распространения вредоносов, если произошел фишинг сотрудника с непривилегированной учетной записью.
Привилегии на ограниченный период
Периодически сотруднику, например, работающему в службе поддержки, на короткое время требуется доступ с высокими привилегиями или доступ к ресурсам, которые обычно не используются. В этом случае имеет смысл наделить учетную запись привилегиями на лету (just-in-time) и на строго отведенное время.
Нулевые привилегии
Наименьшие необходимые привилегии, выдаваемые на лету, могут быть частью философии нулевых привилегий, цель которой – отключение привилегий, выданных на постоянной основе.
Шаги по внедрению модели наименьших привилегий (наилучшие практики)
Для внедрения политики наименьших привилегий следуйте шагам, указанным ниже:
Встроенные административные права.
Принудительное делегирование наименьших привилегий.
Ревизия
Просканируйте и каталогизируйте все системы и директории, подключенные к корпоративной сети. Сделайте ревизию всех учетных записей и групп, включая данные, как, например, срок пароля, время последней авторизации и права доступа.
Оценка привилегий
Идентифицируйте совместно используемые и назначенные привилегированные аккаунты, а также членов групп администраторов, используемых по умолчанию. Выясните, у кого есть привилегированный доступ к серверам и директориям, как, например, Active Directory.
Управление
Внедрите ротацию привилегированных аккаунтов по расписанию с использованием сильных паролей, определяемых соответствующей политикой. У любого решения должна быть возможность предоставить доступ «на лету» и обеспечить ротацию учетных записей, которые оказались обнародованными даже в течение непродолжительного периода времени.
Мониторинг
Выполняйте аудит привилегированных учетных записей и выстройте внутренние процессы, связанные с регулярной сертификацией полномочий и ревизией сессий. Убедитесь, что пользователи имеют привилегии согласно своей роли, а повышенные права вовремя отключаются в случае отсутствия необходимости.
Встроенные административные права
Отключите административные права для рабочих станций, серверов и директорий при помощи технологий на базе агентов или без использования агентов. Убедитесь, что ни у одного пользователя нет административного доступа без прохождения через механизм контроля на основе политик, который выполняет аудит и управляет доступом через политику.
Принудительное делегирование наименьших привилегий
Внедрите политики делегированного доступа, где указаны уровни полномочий для задач без необходимости выдачи полных административных прав. Там, где без административных прав не обойтись, следует назначать эти полномочия только отдельным аккаунтам и вести строгую отчетность. Расширенные права должны выдаваться на ограниченное время и иметь конкретные максимальные сроки действия.
Процедурный уровень информационной безопасности
Основные классы мер процедурного уровня
Мы приступаем к рассмотрению мер безопасности, которые ориентированы на людей, а не на технические средства. Именно люди формируют режим информационной безопасности, и они же оказываются главной угрозой, поэтому » человеческий фактор » заслуживает особого внимания.
В российских компаниях накоплен богатый опыт регламентирования и реализации процедурных (организационных) мер, однако дело в том, что они пришли из «докомпьютерного» прошлого, поэтому требуют переоценки.
Следует осознать ту степень зависимости от компьютерной обработки данных, в которую попало современное общество. Без всякого преувеличения можно сказать, что необходима информационная гражданская оборона. Спокойно, без нагнетания страстей, нужно разъяснять обществу не только преимущества, но и опасности, связанные с использованием информационных технологий. Акцент следует делать не на военной или криминальной стороне дела, а на гражданских аспектах, связанных с поддержанием нормального функционирования аппаратного и программного обеспечения, то есть концентрироваться на вопросах доступности и целостности данных.
На процедурном уровне можно выделить следующие классы мер:
Управление персоналом
Предварительное составление описания должности позволяет оценить ее критичность и спланировать процедуру проверки и отбора кандидатов. Чем ответственнее должность, тем тщательнее нужно проверять кандидатов: навести о них справки, быть может, побеседовать с бывшими сослуживцами и т.д. Подобная процедура может быть длительной и дорогой, поэтому нет смысла дополнительно усложнять ее. В то же время, неразумно и совсем отказываться от предварительной проверки, чтобы случайно не принять на работу человека с уголовным прошлым или психическим заболеванием.
Когда кандидат определен, он, вероятно, должен пройти обучение ; по крайней мере, его следует подробно ознакомить со служебными обязанностями, а также с нормами и процедурами информационной безопасности. Желательно, чтобы меры безопасности были им усвоены до вступления в должность и до заведения его системного счета с входным именем, паролем и привилегиями.
Иногда внешние организации принимают на обслуживание и администрирование ответственные компоненты компьютерной системы, например, сетевое оборудование. Нередко администрирование выполняется в удаленном режиме. Вообще говоря, это создает в системе дополнительные уязвимые места, которые необходимо компенсировать усиленным контролем средств удаленного доступа или, опять-таки, обучением собственных сотрудников.
Процедурный уровень информационной безопасности
Основные классы мер процедурного уровня
Мы приступаем к рассмотрению мер безопасности, которые ориентированы на людей, а не на технические средства. Именно люди формируют режим информационной безопасности, и они же оказываются главной угрозой, поэтому » человеческий фактор » заслуживает особого внимания.
В российских компаниях накоплен богатый опыт регламентирования и реализации процедурных (организационных) мер, однако дело в том, что они пришли из «докомпьютерного» прошлого, поэтому требуют переоценки.
Следует осознать ту степень зависимости от компьютерной обработки данных, в которую попало современное общество. Без всякого преувеличения можно сказать, что необходима информационная гражданская оборона. Спокойно, без нагнетания страстей, нужно разъяснять обществу не только преимущества, но и опасности, связанные с использованием информационных технологий. Акцент следует делать не на военной или криминальной стороне дела, а на гражданских аспектах, связанных с поддержанием нормального функционирования аппаратного и программного обеспечения, то есть концентрироваться на вопросах доступности и целостности данных.
На процедурном уровне можно выделить следующие классы мер:
Управление персоналом
Предварительное составление описания должности позволяет оценить ее критичность и спланировать процедуру проверки и отбора кандидатов. Чем ответственнее должность, тем тщательнее нужно проверять кандидатов: навести о них справки, быть может, побеседовать с бывшими сослуживцами и т.д. Подобная процедура может быть длительной и дорогой, поэтому нет смысла дополнительно усложнять ее. В то же время, неразумно и совсем отказываться от предварительной проверки, чтобы случайно не принять на работу человека с уголовным прошлым или психическим заболеванием.
Когда кандидат определен, он, вероятно, должен пройти обучение ; по крайней мере, его следует подробно ознакомить со служебными обязанностями, а также с нормами и процедурами информационной безопасности. Желательно, чтобы меры безопасности были им усвоены до вступления в должность и до заведения его системного счета с входным именем, паролем и привилегиями.
Иногда внешние организации принимают на обслуживание и администрирование ответственные компоненты компьютерной системы, например, сетевое оборудование. Нередко администрирование выполняется в удаленном режиме. Вообще говоря, это создает в системе дополнительные уязвимые места, которые необходимо компенсировать усиленным контролем средств удаленного доступа или, опять-таки, обучением собственных сотрудников.
Основные программно-технические меры
Архитектурная безопасность
Теоретической основой решения проблемы архитектурной безопасности является следующее фундаментальное утверждение, которое мы уже приводили, рассматривая интерпретацию «Оранжевой книги» для сетевых конфигураций.
Обратим внимание на три принципа, содержащиеся в приведенном утверждении:
Если какой-либо (составной) сервис не обладает полным набором защитных средств (состав полного набора описан выше), необходимо привлечение дополнительных сервисов, которые мы будем называть экранирующими. Экранирующие сервисы устанавливаются на путях доступа к недостаточно защищенным элементам; в принципе, один такой сервис может экранировать (защищать) сколь угодно большое число элементов.
С практической точки зрения наиболее важными являются следующие принципы архитектурной безопасности :
Поясним смысл перечисленных принципов.
Если у злоумышленника или недовольного пользователя появится возможность миновать защитные средства, он, разумеется, так и сделает. Определенные выше экранирующие сервисы должны исключить подобную возможность.
Следование признанным стандартам и использование апробированных решений повышает надежность ИС и уменьшает вероятность попадания в тупиковую ситуацию, когда обеспечение безопасности потребует непомерно больших затрат и принципиальных модификаций.
Иерархическая организация ИС с небольшим числом сущностей на каждом уровне необходима по технологическим соображениям. При нарушении данного принципа система станет неуправляемой и, следовательно, обеспечить ее безопасность будет невозможно.
Применительно к программно-техническому уровню принцип минимизации привилегий предписывает выделять пользователям и администраторам только те права доступа, которые необходимы им для выполнения служебных обязанностей. Этот принцип позволяет уменьшить ущерб от случайных или умышленных некорректных действий пользователей и администраторов.
Принцип разделения обязанностей предполагает такое распределение ролей и ответственности, чтобы один человек не мог нарушить критически важный для организации процесс или создать брешь в защите по заказу злоумышленников. В частности, соблюдение данного принципа особенно важно, чтобы предотвратить злонамеренные или неквалифицированные действия системного администратора.
Для обеспечения высокой доступности (непрерывности функционирования) необходимо соблюдать следующие принципы архитектурной безопасности :
Идентификация и аутентификация, управление доступом
Управление доступом
Основные понятия
С традиционной точки зрения средства управления доступом позволяют специфицировать и контролировать действия, которые субъекты (пользователи и процессы) могут выполнять над объектами (информацией и другими компьютерными ресурсами). В данном разделе речь идет о логическом управлении доступом, которое, в отличие от физического, реализуется программными средствами. Логическое управление доступом – это основной механизм многопользовательских систем, призванный обеспечить конфиденциальность и целостность объектов и, до некоторой степени, их доступность (путем запрещения обслуживания неавторизованных пользователей).
Рассмотрим формальную постановку задачи в традиционной трактовке. Имеется совокупность субъектов и набор объектов. Задача логического управления доступом состоит в том, чтобы для каждой пары «субъект-объект» определить множество допустимых операций (зависящее, быть может, от некоторых дополнительных условий) и контролировать выполнение установленного порядка.
Отношение «субъекты-объекты» можно представить в виде матрицы доступа, в строках которой перечислены субъекты, в столбцах – объекты, а в клетках, расположенных на пересечении строк и столбцов, записаны дополнительные условия (например, время и место действия) и разрешенные виды доступа. Фрагмент матрицы может выглядеть, например, так:
| Файл | Программа | Линия связи | Реляционная таблица |
|---|---|---|---|
| Пользователь 1 | orw с системной консоли | e | rw с 8:00 до 18:00 |
| Пользователь 2 | a |
«o» – обозначает разрешение на передачу прав доступа другим пользователям,
«a» – добавление информации
Тема логического управления доступом – одна из сложнейших в области информационной безопасности. Дело в том, что само понятие объекта (а тем более видов доступа) меняется от сервиса к сервису. Для операционной системы к объектам относятся файлы, устройства и процессы. Применительно к файлам и устройствам обычно рассматриваются права на чтение, запись, выполнение (для программных файлов), иногда на удаление и добавление. Отдельным правом может быть возможность передачи полномочий доступа другим субъектам (так называемое право владения). Процессы можно создавать и уничтожать. Современные операционные системы могут поддерживать и другие объекты.
Для систем управления реляционными базами данных объект – это база данных, таблица, представление, хранимая процедура. К таблицам применимы операции поиска, добавления, модификации и удаления данных, у других объектов иные виды доступа.
Разнообразие объектов и применимых к ним операций приводит к принципиальной децентрализации логического управления доступом. Каждый сервис должен сам решать, позволить ли конкретному субъекту ту или иную операцию. Теоретически это согласуется с современным объектно-ориентированным подходом, на практике же приводит к значительным трудностям. Главная проблема в том, что ко многим объектам можно получить доступ с помощью разных сервисов (возможно, при этом придется преодолеть некоторые технические трудности). Так, до реляционных таблиц можно добраться не только средствами СУБД, но и путем непосредственного чтения файлов или дисковых разделов, поддерживаемых операционной системой (разобравшись предварительно в структуре хранения объектов базы данных). В результате при задании матрицы доступа нужно принимать во внимание не только принцип распределения привилегий для каждого сервиса, но и существующие связи между сервисами (приходится заботиться о согласованности разных частей матрицы). Аналогичная трудность возникает при экспорте/импорте данных, когда информация о правах доступа, как правило, теряется (поскольку на новом сервисе она не имеет смысла). Следовательно, обмен данными между различными сервисами представляет особую опасность с точки зрения управления доступом, а при проектировании и реализации разнородной конфигурации необходимо позаботиться о согласованном распределении прав доступа субъектов к объектам и о минимизации числа способов экспорта/импорта данных.
При принятии решения о предоставлении доступа обычно анализируется следующая информация:
Матрицу доступа, ввиду ее разреженности (большинство клеток – пустые), неразумно хранить в виде двухмерного массива. Обычно ее хранят по столбцам, то есть для каждого объекта поддерживается список «допущенных» субъектов вместе с их правами. Элементами списков могут быть имена групп и шаблоны субъектов, что служит большим подспорьем администратору. Некоторые проблемы возникают только при удалении субъекта, когда приходится удалять его имя из всех списков доступа; впрочем, эта операция производится не часто.
Второй недостаток, который представляется основным, состоит в том, что права доступа существуют отдельно от данных. Ничто не мешает пользователю, имеющему доступ к секретной информации, записать ее в доступный всем файл или заменить полезную утилиту ее «троянским» аналогом. Подобная «разделенность» прав и данных существенно осложняет проведение несколькими системами согласованной политики безопасности и, главное, делает практически невозможным эффективный контроль согласованности.
Возвращаясь к вопросу представления матрицы доступа, укажем, что для этого можно использовать также функциональный способ, когда матрицу не хранят в явном виде, а каждый раз вычисляют содержимое соответствующих клеток. Например, при принудительном управлении доступом применяется сравнение меток безопасности субъекта и объекта.
Удобной надстройкой над средствами логического управления доступом является ограничивающий интерфейс, когда пользователя лишают самой возможности попытаться совершить несанкционированные действия, включив в число видимых ему объектов только те, к которым он имеет доступ. Подобный подход обычно реализуют в рамках системы меню (пользователю показывают лишь допустимые варианты выбора) или посредством ограничивающих оболочек, таких как restricted shell в ОС Unix.
В заключение подчеркнем важность управления доступом не только на уровне операционной системы, но и в рамках других сервисов, входящих в состав современных приложений, а также, насколько это возможно, на «стыках» между сервисами. Здесь на первый план выходит существование единой политики безопасности организации, а также квалифицированное и согласованное системное администрирование.
Ролевое управление доступом
При большом количестве пользователей традиционные подсистемы управления доступом становятся крайне сложными для администрирования. Число связей в них пропорционально произведению количества пользователей на количество объектов. Необходимы решения в объектно-ориентированном стиле, способные эту сложность понизить.
Таким решением является ролевое управление доступом (РУД). Суть его в том, что между пользователями и их привилегиями появляются промежуточные сущности – роли. Для каждого пользователя одновременно могут быть активными несколько ролей, каждая из которых дает ему определенные права (см. рис. 10.2).
Ролевой доступ нейтрален по отношению к конкретным видам прав и способам их проверки; его можно рассматривать как объектно-ориентированный каркас, облегчающий администрирование, поскольку он позволяет сделать подсистему разграничения доступа управляемой при сколь угодно большом числе пользователей, прежде всего за счет установления между ролями связей, аналогичных наследованию в объектно-ориентированных системах. Кроме того, ролей должно быть значительно меньше, чем пользователей. В результате число администрируемых связей становится пропорциональным сумме (а не произведению) количества пользователей и объектов, что по порядку величины уменьшить уже невозможно.
Ролевое управление доступом оперирует следующими основными понятиями:
Ролям приписываются пользователи и права доступа ; можно считать, что они (роли) именуют отношения «многие ко многим» между пользователями и правами. Роли могут быть приписаны многим пользователям; один пользователь может быть приписан нескольким ролям. Во время сеанса работы пользователя активизируется подмножество ролей, которым он приписан, в результате чего он становится обладателем объединения прав, приписанных активным ролям. Одновременно пользователь может открыть несколько сеансов.
Отношение наследования является иерархическим, причем права доступа и пользователи распространяются по уровням иерархии навстречу друг другу. В общем случае наследование является множественным, то есть у одной роли может быть несколько предшественниц (и, естественно, несколько наследниц, которых мы будем называть также преемницами).
Можно представить себе формирование иерархии ролей, начиная с минимума прав (и максимума пользователей), приписываемых роли «сотрудник», с постепенным уточнением состава пользователей и добавлением прав (роли «системный администратор», «бухгалтер» и т.п.), вплоть до роли «руководитель» (что, впрочем, не значит, что руководителю предоставляются неограниченные права; как и другим ролям, в соответствии с принципом минимизации привилегий, этой роли целесообразно разрешить только то, что необходимо для выполнения служебных обязанностей). Фрагмент подобной иерархии ролей показан на рис. 10.3.
Для реализации еще одного упоминавшегося ранее важного принципа информационной безопасности вводится понятие разделения обязанностей, причем в двух видах: статическом и динамическом.
Статическое разделение обязанностей налагает ограничения на приписывание пользователей ролям. В простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному множеству других ролей. В общем случае данное ограничение задается как пара «множество ролей – число» (где множество состоит, по крайней мере, из двух ролей, а число должно быть больше 1), так что никакой пользователь не может быть приписан указанному (или большему) числу ролей из заданного множества. Например, может существовать пять бухгалтерских ролей, но политика безопасности допускает членство не более чем в двух таких ролях (здесь число=3).
При наличии наследования ролей ограничение приобретает несколько более сложный вид, но суть остается простой: при проверке членства в ролях нужно учитывать приписывание пользователей ролям-наследницам.
Все остальные функции отнесены к разряду необязательных. Это получение информации о правах, приписанных роли, о правах заданного пользователя (которыми он обладает как член множества ролей), об активных в данный момент сеанса ролях и правах, об операциях, которые роль/пользователь правомочны совершить над заданным объектом, о статическом/динамическом разделении обязанностей.
Можно надеяться, что предлагаемый стандарт поможет сформировать единую терминологию и, что более важно, позволит оценивать РУД-продукты с единых позиций, по единой шкале.