|
|
@@ -0,0 +1,253 @@
|
|
|
+# 1.5.100 Идентификация, авторизация и аутентификация субъектов доступа и объектов доступа
|
|
|
+
|
|
|
+Данная тема является **фундаментальной для всей системы защиты информации**. Идентификация, аутентификация и авторизация — это не просто «три умных слова», а **последовательные этапы одного процесса управления доступом**, без которых невозможно обеспечить безопасность ни одной информационной системы.
|
|
|
+
|
|
|
+## 📌 Ключевые понятия: разграничиваем термины
|
|
|
+
|
|
|
+Многие путают эти понятия или используют их как синонимы, что **методологически неверно**. Рассмотрим каждое определение строго.
|
|
|
+
|
|
|
+### 🆔 Идентификация — «Кто ты?»
|
|
|
+
|
|
|
+**Идентификация** — это действия по **присвоению** субъектам и объектам доступа идентификаторов и (или) по **сравнению** предъявляемого идентификатора с перечнем присвоенных идентификаторов.
|
|
|
+
|
|
|
+**Простыми словами:** Пользователь сообщает системе, кем он является. Это может быть ввод логина, предъявление пропуска, называние имени.
|
|
|
+
|
|
|
+**Ключевой момент:** На этапе идентификации система еще **не проверяет**, действительно ли вы — это вы. Она просто фиксирует, что некто **заявил** себя как «Иван Петров». Идентификация может быть:
|
|
|
+
|
|
|
+- **Первичной** — при регистрации нового пользователя в системе (присвоение уникального ID).
|
|
|
+- **Вторичной** — при каждом последующем запросе на доступ (сравнение заявленного ID с базой).
|
|
|
+
|
|
|
+### 🔐 Аутентификация — «Докажи, что это ты»
|
|
|
+
|
|
|
+**Аутентификация** — это действия по **проверке подлинности** субъекта (или объекта) доступа, а также по проверке **принадлежности** субъекту предъявленного идентификатора и аутентификационной информации.
|
|
|
+
|
|
|
+**Простыми словами:** Система требует доказательств того, что вы — именно тот, за кого себя выдаете. Пароль, отпечаток пальца, код из СМС — все это инструменты аутентификации.
|
|
|
+
|
|
|
+**Ключевой момент:** Аутентификация **основывается на проверке соответствия** аутентификационной информации, предъявленной субъектом, и той информации, которая **ассоциирована** с этим идентификатором в системе. Именно на этом этапе система отвечает на вопрос: «Действительно ли этот человек — Иван Петров?»
|
|
|
+
|
|
|
+### 🚪 Авторизация — «Что тебе можно?»
|
|
|
+
|
|
|
+**Авторизация** — это предоставление конкретному пользователю **доступа к определенным системным ресурсам**.
|
|
|
+
|
|
|
+**Простыми словами:** После успешной аутентификации система решает, **что именно** вам разрешено делать. Можете ли вы читать этот файл? Имеете ли право изменять настройки? Доступна ли вам эта база данных?
|
|
|
+
|
|
|
+**Ключевой момент:** Авторизация определяет **объем прав** пользователя. Даже если вы успешно аутентифицировались как Иван Петров, это не значит, что вам разрешено **все**. Вы получаете доступ только к тем ресурсам, которые предусмотрены вашей ролью.
|
|
|
+
|
|
|
+## ⛓️ Логическая цепочка: как это работает на практике
|
|
|
+
|
|
|
+Эти три процесса образуют **строгую последовательность**, нарушение которой создает уязвимости.
|
|
|
+
|
|
|
+**Идентификация → Аутентификация → Авторизация**
|
|
|
+
|
|
|
+1. **Пользователь вводит логин.** (Идентификация)
|
|
|
+2. **Пользователь вводит пароль.** (Аутентификация)
|
|
|
+3. **Система предоставляет доступ к разрешенным ресурсам.** (Авторизация)
|
|
|
+
|
|
|
+**⚠️ Важно:** Авторизация **невозможна** без успешной аутентификации. А аутентификация **бессмысленна** без идентификации (некого проверять). Это **единый контур управления доступом**.
|
|
|
+
|
|
|
+## 🎯 Факторы аутентификации: на чем основывается доказательство
|
|
|
+
|
|
|
+Согласно ГОСТ Р 58833-2020, в процессе аутентификации применяются следующие **факторы**:
|
|
|
+
|
|
|
+| Фактор | Суть | Примеры |
|
|
|
+|--------|------|---------|
|
|
|
+| **Фактор знания** | То, что субъект **знает** | Пароль, PIN-код, секретный вопрос |
|
|
|
+| **Фактор владения** | То, чем субъект **обладает** | Токен, смарт-карта, аппаратный ключ |
|
|
|
+| **Биометрический фактор** | То, что **свойственно** субъекту | Отпечаток пальца, сетчатка глаза, голос |
|
|
|
+
|
|
|
+**Многофакторная аутентификация** — это использование **одновременно не менее двух различных факторов**. Например, пароль + код из СМС (знание + владение).
|
|
|
+
|
|
|
+## 💻 Методы аутентификации: от простого к сложному
|
|
|
+
|
|
|
+### 🔑 Парольная аутентификация
|
|
|
+
|
|
|
+**Самый распространенный**, но и **самый уязвимый** метод. Его слабости хорошо известны: пользователи выбирают простые пароли, используют один пароль для разных систем, пароли можно подсмотреть или подобрать.
|
|
|
+
|
|
|
+### 🔢 Одноразовые пароли (OTP)
|
|
|
+
|
|
|
+**Динамические данные аутентификации**, меняющиеся с каждым сеансом. Перехваченный пароль **не может быть использован повторно**. Это **устойчивая аутентификация**.
|
|
|
+
|
|
|
+### 🖐️ Биометрическая аутентификация
|
|
|
+
|
|
|
+Использование **уникальных физических характеристик**. Теоретически **самый надежный** метод, но на практике сталкивается с проблемами: ошибки ложного отказа, изменения биометрии со временем, сложности удаленной проверки.
|
|
|
+
|
|
|
+### 🛡️ Криптографическая аутентификация
|
|
|
+
|
|
|
+**Строгая аутентификация** на основе криптографических методов и средств. Обеспечивает **постоянную аутентификацию** — защиту от активных атак, когда злоумышленник может изменять данные в потоке.
|
|
|
+
|
|
|
+## ⚖️ Нормативная база: что говорит закон и стандарты
|
|
|
+
|
|
|
+### 📜 ГОСТ Р 58833-2020
|
|
|
+
|
|
|
+**Ключевой документ** в области идентификации и аутентификации. Устанавливает **единообразную организацию процессов** идентификации и аутентификации в средствах защиты информации.
|
|
|
+
|
|
|
+**Основные положения:**
|
|
|
+- Аутентификация следует за процессом **вторичной идентификации** при каждом запросе на доступ.
|
|
|
+- Доказательство подлинности должно основываться на **проверке соответствия** аутентификационной информации.
|
|
|
+- Цель аутентификации — формирование **необходимой уверенности** в том, что субъект действительно является зарегистрированным субъектом.
|
|
|
+
|
|
|
+### 📋 Приказ ФСБ России от 10.07.2014 № 378
|
|
|
+
|
|
|
+Регламентирует **организационные и технические меры** по обеспечению безопасности персональных данных с использованием СКЗИ. В контексте идентификации и аутентификации устанавливает требования к **хранению носителей** ключевой, аутентифицирующей и парольной информации.
|
|
|
+
|
|
|
+**Требования для 4 уровня защищенности:**
|
|
|
+- Организация режима безопасности помещений.
|
|
|
+- Обеспечение сохранности носителей персональных данных.
|
|
|
+- Утверждение перечня лиц, имеющих доступ к ПДн.
|
|
|
+- Использование сертифицированных средств защиты.
|
|
|
+
|
|
|
+### ⚠️ Требования ФСТЭК России
|
|
|
+
|
|
|
+Приказ ФСТЭК России от 18.02.2013 № 21 устанавливает **меры ЗИС.3** (идентификация и аутентификация пользователей). Для соответствующих уровней защищенности требуются:
|
|
|
+- СКЗИ **не ниже класса КС1**.
|
|
|
+- Средства вычислительной техники **не ниже 5 класса**.
|
|
|
+- Межсетевые экраны **не ниже 6 класса**.
|
|
|
+
|
|
|
+## 🚨 Типичные ошибки и уязвимости
|
|
|
+
|
|
|
+### ❌ Использование одного фактора там, где нужен многофакторный
|
|
|
+
|
|
|
+Пароль может быть скомпрометирован. Для доступа к критичным ресурсам необходим **второй фактор**.
|
|
|
+
|
|
|
+### ❌ Идентификация без аутентификации
|
|
|
+
|
|
|
+Предоставление доступа на основе только заявленного идентификатора — **грубейшая ошибка**. «Я — администратор» не означает, что вы им являетесь.
|
|
|
+
|
|
|
+### ❌ Аутентификация без авторизации
|
|
|
+
|
|
|
+Проверка подлинности без разграничения прав приводит к тому, что **любой аутентифицированный пользователь** получает доступ ко **всем** ресурсам.
|
|
|
+
|
|
|
+### ❌ Хранение паролей в открытом виде
|
|
|
+
|
|
|
+Даже на этапе идентификации система не должна «знать» пароль пользователя — она должна хранить его **хеш**.
|
|
|
+
|
|
|
+## 🎬 СЦЕНАРИЙ: «Один день из жизни системы управления доступом»
|
|
|
+
|
|
|
+> **Это сквозной практический пример, который связывает все три процесса воедино. Именно его чаще всего требуют на защите.**
|
|
|
+
|
|
|
+### 📖 Легенда
|
|
|
+
|
|
|
+В организации **ООО «Ромашка»** развернута корпоративная информационная система (КИС). В ней работают:
|
|
|
+- **Иван Петров** — бухгалтер (доступ к 1С и папке «Бухгалтерия»).
|
|
|
+- **Анна Смирнова** — HR-специалист (доступ к папке «Кадры» и системе электронного документооборота).
|
|
|
+- **Сергей Кузнецов** — системный администратор (полный доступ).
|
|
|
+
|
|
|
+В системе реализованы: **идентификация по логину**, **аутентификация по паролю + одноразовый код из токена**, **авторизация на основе ролей (RBAC)**.
|
|
|
+
|
|
|
+### 🎭 Акт 1. Идентификация — «Представься»
|
|
|
+
|
|
|
+**Утро. Иван Петров приходит на работу и включает компьютер.**
|
|
|
+
|
|
|
+1. На экране — окно входа в КИС. Система запрашивает: **«Введите логин»**.
|
|
|
+2. Иван вводит: `petrov_ii`.
|
|
|
+3. Система проверяет: **существует ли такой идентификатор в базе?**
|
|
|
+
|
|
|
+**Что происходит внутри:**
|
|
|
+- Система **не знает**, кто сидит за компьютером.
|
|
|
+- Она видит лишь строку `petrov_ii` и сверяет её со списком зарегистрированных пользователей.
|
|
|
+- Если логина нет — система откажет **до** любой проверки пароля.
|
|
|
+
|
|
|
+**✅ Результат этапа:** Система зафиксировала: «Некто заявил, что он — пользователь с ID `petrov_ii`».
|
|
|
+
|
|
|
+**❌ Что было бы, если пропустить этап:** Система не знала бы, чей пароль проверять дальше.
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 🎭 Акт 2. Аутентификация — «Докажи, что ты — это ты»
|
|
|
+
|
|
|
+**Система запрашивает пароль.**
|
|
|
+
|
|
|
+1. Иван вводит пароль: `Qwerty123` (он его знает — **фактор знания**).
|
|
|
+2. Система вычисляет **хеш** от введённого пароля и сравнивает с **хешем**, хранящимся в базе для пользователя `petrov_ii`.
|
|
|
+3. Хеши совпадают — **первый фактор пройден**.
|
|
|
+4. Система запрашивает **второй фактор**: «Введите код с токена».
|
|
|
+5. Иван смотрит на токен (**фактор владения**) и вводит 6-значный код: `482913`.
|
|
|
+6. Система проверяет код по алгоритму OTP. Код верный — **второй фактор пройден**.
|
|
|
+
|
|
|
+**✅ Результат этапа:** Система **уверена**, что за компьютером — именно Иван Петров, а не злоумышленник, который украл логин и пароль.
|
|
|
+
|
|
|
+**❌ Что было бы, если пропустить этап:** Любой, кто знал бы логин `petrov_ii`, получил бы доступ. Пароль мог быть подсмотрен, перехвачен фишингом или подобран.
|
|
|
+
|
|
|
+**⚠️ Важный нюанс:** Если бы Иван ввёл неверный пароль **три раза подряд**, сработала бы **блокировка учётной записи** — это элемент защиты от ** brute-force атаки**.
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 🎭 Акт 3. Авторизация — «Вот что тебе можно»
|
|
|
+
|
|
|
+**Иван успешно прошёл идентификацию и аутентификацию. Что дальше?**
|
|
|
+
|
|
|
+1. Система обращается к **матрице доступа** (ролевой модели).
|
|
|
+2. Смотрит: пользователь `petrov_ii` имеет роль **«Бухгалтер»**.
|
|
|
+3. Роль «Бухгалтер» даёт права:
|
|
|
+ - ✅ **Чтение и запись** в папке `\\server\Бухгалтерия`
|
|
|
+ - ✅ **Доступ** к системе 1С:Бухгалтерия
|
|
|
+ - ❌ **Запрет** на папку `\\server\Кадры`
|
|
|
+ - ❌ **Запрет** на изменение системных настроек
|
|
|
+ - ❌ **Запрет** на доступ к базе данных клиентов
|
|
|
+
|
|
|
+4. Иван пытается открыть папку `\\server\Кадры` — система **отказывает в доступе**.
|
|
|
+
|
|
|
+**✅ Результат этапа:** Иван получил **ровно те права**, которые нужны для его работы. Не больше.
|
|
|
+
|
|
|
+**❌ Что было бы, если пропустить этап:** Иван, как аутентифицированный пользователь, получил бы доступ ко **всей** корпоративной сети, включая зарплаты коллег, кадровые документы и систему бэкапов. Это — **катастрофа**.
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 🎭 Акт 4. Атака: что если злоумышленник?
|
|
|
+
|
|
|
+**Сценарий:** Злоумышленник украл логин и пароль Ивана через фишинг.
|
|
|
+
|
|
|
+1. **Идентификация:** Злоумышленник вводит `petrov_ii` — система принимает (логин верный).
|
|
|
+2. **Аутентификация:** Злоумышленник вводит украденный пароль `Qwerty123` — **первый фактор пройден**.
|
|
|
+3. **Система запрашивает код с токена.** У злоумышленника токена **нет**. Он вводит случайный код `000000`.
|
|
|
+4. **Система отказывает.** Доступ **не предоставлен**.
|
|
|
+
|
|
|
+**✅ Вывод:** Именно **многофакторная аутентификация** спасла систему. Даже компрометация пароля не дала злоумышленнику доступа.
|
|
|
+
|
|
|
+**А если бы был только пароль?** Злоумышленник прошёл бы аутентификацию и, в зависимости от авторизации, получил бы доступ к бухгалтерским данным.
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 🎭 Акт 5. Особый случай: объект доступа
|
|
|
+
|
|
|
+**Важно:** Идентификация и аутентификация применяются **не только к людям**, но и к **объектам доступа** — устройствам, процессам, сервисам.
|
|
|
+
|
|
|
+**Пример:** Сервер 1С обращается к базе данных на другом сервере.
|
|
|
+
|
|
|
+1. **Идентификация:** Сервер 1С представляется: `app_server_1c`.
|
|
|
+2. **Аутентификация:** Предъявляет **сертификат** или **ключ** (криптографическая аутентификация).
|
|
|
+3. **Авторизация:** База данных проверяет: имеет ли `app_server_1c` право на чтение таблицы `Зарплата`? Да, имеет. На запись в `Системные_таблицы`? Нет, не имеет.
|
|
|
+
|
|
|
+**✅ Вывод:** Принципы **едины** для людей и для машин. Это важно для **микросервисной архитектуры**, **IoT** и **облачных сред**.
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 📊 Итоговая таблица сценария
|
|
|
+
|
|
|
+| Этап | Вопрос | Что делает Иван | Что делает система | Что если пропустить |
|
|
|
+|------|--------|-----------------|-------------------|---------------------|
|
|
|
+| **Идентификация** | Кто ты? | Вводит логин | Сверяет с базой | Не знает, чей пароль проверять |
|
|
|
+| **Аутентификация** | Докажи | Пароль + код с токена | Проверяет хеш и OTP | Любой с логином получит доступ |
|
|
|
+| **Авторизация** | Что можно? | Пытается открыть папку | Проверяет роль и права | Пользователь получает всё |
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 🎓 Мораль сценария
|
|
|
+
|
|
|
+> **Идентификация** — это **заявление**.
|
|
|
+> **Аутентификация** — это **доказательство**.
|
|
|
+> **Авторизация** — это **разрешение**.
|
|
|
+>
|
|
|
+> Только **все три этапа вместе** обеспечивают **управление доступом**. Пропуск любого звена — **дыра в безопасности**.
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 💎 Резюме: почему это важно
|
|
|
+
|
|
|
+**Идентификация, аутентификация и авторизация** — это **триединство управления доступом**. Они работают только **вместе**:
|
|
|
+
|
|
|
+- Без **идентификации** система не знает, кого проверять.
|
|
|
+- Без **аутентификации** система не может доверять заявленному идентификатору.
|
|
|
+- Без **авторизации** система не знает, что разрешить аутентифицированному пользователю.
|
|
|
+
|
|
|
+**Нарушение любого звена** этой цепочки создает **уязвимость**. Именно поэтому данная тема является **базовой** для всей дисциплины «Защита информации» и **обязательной** для изучения в контексте требований регуляторов.
|
