В своей последней публикации Что такое авторизация и управление доступом говорилось, что мы используем аутентификацию для проверки личности – чтобы подтвердить, что пользователь именно тот, за кого себя выдает – а также для осуществления политики авторизации, то есть определения, что пользователь имеет право «просматривать и делать». Мы реализуем эти аспекты политики авторизации с помощью мер безопасности, открывая или запрещая доступ к ресурсам, которые мы намерены контролировать или защищать.
Меры, которые мы используем для реализации политики авторизации, называются средствами регулирования доступа пользователей, разрешениями или привилегиями пользователей. Управление доступом пользователей обычно применяется в операционных системах Windows, в документации к маршрутизаторам или брандмауэрам, а в документации Linux более распространен термин «привилегии пользователей» или «разрешения пользователей». Вы можете найти целые ветки дискуссий, посвященных различиям между этими терминами, но для ознакомительных целей можно считать их взаимозаменяемыми. Используйте термин, наиболее удобный для себя или чаще всего встречающийся в литературе, с которой вы имеете дело.
Определяя политику авторизации, вы определяете индивидуальных пользователей или их группы, приложения или процессы, которые могут осуществлять действия в отношении ресурса, например базы данных. Политика авторизации может быть очень детальной. Вы можете управлять действиями – смогут или нет отдельные пользователи или группы пользователей читать, создавать или изменять (записывать), удалять – отдельные записи базы данных или даже отдельные элементы (поля) записи базы данных.
Пример политики авторизации
Представим себе торговую базу данных, в которой каждая запись содержит имя, домашний адрес, телефон и данные кредитной карты. ИТ-персонал торговой организации определяет политику авторизации, на основании которой доступ сотрудников будет осуществляться по трем уровням привилегий:
-
Администраторы базы данных, Джо и Терри, могут выполнять любые действия с любой записью базы данных. Например, они могут создавать записи, изменять любые элементы любой записи, а также удалять любую запись.
Это пример полного доступа.
-
Сотрудники бухгалтерии, Шарлотта и Берт, могут читать все поля клиентской записи, включая данные кредитной карты, но не могут создавать, изменять и удалять записи или отдельные поля записей.
Здесь мы разрешаем доступ ко всем записям, но запрещаем функции создания, изменения и удаления записей или отдельных полей.
-
Сотрудники службы маркетинга, Ахмед и Карло, могут читать все клиентские записи, кроме данных кредитных карт; кроме того, они не могут создавать, изменять и удалять записи или отдельные поля записей.
Здесь мы разрешаем доступ ко всем записям, но запрещаем доступ к определенным данным в каждой записи.
Эти примеры иллюстрируют важную концепцию безопасности, принцип минимальной привилегии (POLP), когда организация предоставляет пользователям только те привилегии, которые им необходимы для выполнения своих должностных обязанностей. Например, наша вымышленная компания определила, что сотрудникам службы маркетинга не нужен доступ к кредитным картам. Кроме того, наши примеры иллюстрируют управление доступом на основе ролей (RBAC). В этих примерах компания установила привилегии на основе набора ролей {администратор базы данных, персонал бухгалтерии, персонал службы маркетинга…}.
Закладка основ
Рассмотрите средства управления доступом в нашем примере и задайте вопрос: «Если вы хакер и хотите украсть информацию, которая позволит осуществлять мошеннические операции с кредитными картами – к каким учетным записям вы бы захотели получить доступ?»
В следующей публикации мы рассмотрим, как хакеры пытаются получать доступ и повышать уровень привилегий.