Причины:
- Отсутствие формальной процедуры верификации запросов.
- Использование одного канала связи (например, только email) — подделка отправителя.
- Игнорирование технических индикаторов подлинности (SPF/DKIM/DMARC, IP-адреса, временные метки).
Решение:
1. Проверить техническую подлинность письма (если запрос через email):
- Просмотр заголовков письма (в Outlook: `Свойства` → `Интернет-заголовки`; в Thunderbird: `Вид` → `Исходный текст`).
- Команда для проверки SPF-записи домена отправителя:
bash
nslookup -type=txt domain.ru | grep spf- Проверка DKIM-подписи: значение `d=` должно совпадать с доменом отправителя.
- DMARC-политика: `dig _dmarc.domain.ru TXT` (ожидается `p=reject` или `p=quarantine`).
2. Верификация по альтернативному каналу (обязательно!):
- Позвонить коллеге по номеру из корпоративной телефонной книги (не из письма).
- Использовать корпоративный мессенджер с подтверждением (например, Slack/Teams с запросом в личное сообщение).
3. Запросить цифровую подпись (GPG/PGP):
- Если в организации принято — коллега подписывает запрос своим приватным ключом. Проверка:
bash
gpg --verify request.txt.sig request.txt- Сертификат S/MIME — проверить цепочку сертификата (должен быть выпущен корпоративным УЦ).
4. Использовать формальный workflow:
- Запрос должен быть создан через систему тикетов (Jira, ServiceNow) с обязательной электронной подписью или approval от руководителя.
- При автоматизации — внедрить OAuth 2.0 Device Authorization Grant для временного доступа.
5. Проверка метаданных: IP-адрес отправителя (если доступен) — должен совпадать с корпоративным диапазоном (например, 10.x.x.x или white-list). Сравнить время запроса с рабочим графиком коллеги.
Пример проверки SPF/DKIM/DMARC одной командой:
bash
dig TXT +short _dmarc.domain.ru && dig TXT +short domain.ru | grep spf && dig TXT +short dkim._domainkey.domain.ru