> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/guide/nachalo-raboty/centr-bezopasnosti/operacionnaya-bezopasnost-opsec.md).

# Операционная безопасность (OPSEC)

Настоящий документ определяет базовые требования по обеспечению операционной безопасности (OPSEC) для владельцев, администраторов, сотрудников и подрядчиков, использующих программное обеспечение iEXExchanger.

Цель документа — минимизировать риск несанкционированного доступа, компрометации данных, финансовых потерь, остановки работы сервиса и других инцидентов информационной безопасности.

Требования данного документа рекомендуется применять ко всем системам, связанным с работой обменного пункта:

* серверы;
* административные панели;
* электронная почта;
* Telegram;
* домены и DNS;
* Cloudflare;
* GitHub;
* платёжные системы;
* криптовалютные кошельки;
* рабочие устройства сотрудников.

***

## Международные стандарты безопасности

Политика безопасности iEXExchanger основана на рекомендациях следующих стандартов:

#### NIST Cybersecurity Framework

Международный стандарт управления кибербезопасностью, используемый государственными структурами и коммерческими организациями.

Основные принципы:

* Identify (идентификация рисков);
* Protect (защита);
* Detect (обнаружение угроз);
* Respond (реагирование);
* Recover (восстановление).

#### ISO/IEC 27001

Международный стандарт построения системы управления информационной безопасностью.

Основные требования:

* контроль доступа;
* управление рисками;
* резервное копирование;
* аудит действий пользователей;
* управление инцидентами безопасности.

#### CIS Controls

Практический набор рекомендаций по защите инфраструктуры.

Особое внимание уделяется:

* защите учётных записей;
* обновлению программного обеспечения;
* контролю доступа;
* защите конечных устройств;
* журналированию событий.

#### Zero Trust Security Model

Современная модель безопасности, основанная на принципе:

Никому не доверяй по умолчанию. Проверяй всё.

Каждый пользователь, устройство и запрос должны проходить проверку независимо от их происхождения.

***

## Основные угрозы

### Социальная инженерия

Попытка получить доступ путём обмана сотрудников или владельца проекта.

Примеры:

* сообщения от имени разработчиков;
* просьбы предоставить доступ к серверу;
* запросы на передачу резервных копий;
* предложения установить неизвестные программы.

***

### Фишинг

Создание поддельных сайтов, страниц авторизации и почтовых сообщений для кражи учётных данных.

***

### DDoS-атаки

Перегрузка сервиса большим количеством запросов с целью остановки работы обменного пункта.

***

### Вредоносное ПО

Использование:

* троянов;
* стилеров;
* кейлоггеров;
* вредоносных расширений браузера;
* программ удалённого доступа.

***

### Компрометация учётных записей

Получение злоумышленниками доступа к:

* серверу;
* панели управления;
* электронной почте;
* Telegram;
* Cloudflare;
* домену;
* платёжным системам.

***

### Ошибки сотрудников

Наиболее частая причина инцидентов:

* передача доступов третьим лицам;
* использование слабых паролей;
* работа без MFA;
* открытие подозрительных вложений.

***

## Политика управления доступом

### Принцип минимальных привилегий

Каждый пользователь должен иметь только тот уровень доступа, который необходим для выполнения его задач.

Запрещается выдавать:

* полный доступ подрядчикам;
* root-доступ без необходимости;
* общие учётные записи нескольким сотрудникам.

***

### Индивидуальные учётные записи

Каждый сотрудник должен использовать собственную учётную запись.

Запрещается:

* использовать общий логин;
* передавать свои данные авторизации другим лицам.

***

### Временные доступы

Все временные доступы должны иметь срок действия.

После завершения работ доступ должен быть:

* удалён;
* заблокирован;
* заменён новым при необходимости.

***

## Политика паролей

Минимальные требования:

* длина не менее 16 символов;
* использование строчных и заглавных букв;
* использование цифр;
* использование специальных символов.

Рекомендуется использовать менеджеры паролей.

Запрещается:

* хранить пароли в текстовых файлах;
* использовать одинаковые пароли;
* передавать пароли через обычные сообщения.

***

## Многофакторная аутентификация (MFA)

Обязательна для:

* FastPanel;
* Cloudflare;
* электронной почты;
* Telegram;
* GitHub;
* административной панели;
* доменного регистратора;
* платёжных систем.

Предпочтительно использовать приложения-аутентификаторы:

* Google Authenticator;
* Microsoft Authenticator;
* 2FAS;
* Aegis.

SMS-аутентификация рекомендуется только как резервный вариант.

***

## Безопасность сервера

Для серверов Debian рекомендуется:

#### Обязательно

* использовать SSH-ключи;
* отключить вход root по паролю;
* установить UFW;
* установить Fail2Ban;
* регулярно обновлять систему;
* использовать отдельного пользователя для работы.

#### Рекомендуется

* ограничить SSH по IP;
* изменить стандартный порт SSH;
* использовать мониторинг сервера;
* использовать отдельный сервер для production.

***

## Безопасность электронной почты

Почта является критически важным элементом безопасности.

Обязательно:

* включить MFA;
* использовать отдельный адрес для администрирования;
* настроить SPF;
* настроить DKIM;
* настроить DMARC.

Не открывайте вложения и ссылки от неизвестных отправителей.

***

## Безопасность Telegram

Обязательно:

* включить Two-Step Verification;
* использовать пароль не менее 16 символов;
* регулярно проверять активные сессии;
* удалять неизвестные устройства.

Никогда не передавайте:

* коды подтверждения;
* резервные коды;
* данные активных сессий.

***

## Cloudflare и защита периметра

Рекомендуемые меры:

* скрыть реальный IP сервера;
* включить WAF;
* включить Bot Protection;
* настроить Rate Limiting;
* ограничить доступ к панели управления по IP;
* использовать режим Under Attack при необходимости.

***

## Безопасность рабочих устройств

Рекомендуется:

* использовать отдельное устройство для администрирования;
* включить шифрование диска;
* использовать антивирусное ПО;
* регулярно обновлять операционную систему;
* использовать отдельный профиль браузера для работы.

***

## Работа с подрядчиками

Перед выдачей доступа:

1. Создайте отдельную учётную запись.
2. Ограничьте доступ необходимыми правами.
3. Ограничьте доступ по IP при возможности.
4. Зафиксируйте срок действия доступа.

После завершения работ:

1. Удалите доступ.
2. Удалите SSH-ключи.
3. Проверьте журналы действий.
4. Смените пароли при необходимости.

***

## Резервное копирование

Рекомендуется соблюдать правило:

#### 3-2-1

* 3 копии данных;
* 2 разных носителя хранения;
* 1 копия вне основного сервера.

Резервному копированию подлежат:

* файлы проекта;
* база данных;
* конфигурации сервера;
* резервные коды MFA;
* SSL-сертификаты.

***

## Контрольный список владельца

### Ежедневно

* Проверить входы в Telegram.
* Проверить входы в почту.
* Проверить административные логи.
* Проверить уведомления Cloudflare.

### Еженедельно

* Проверить журналы SSH.
* Проверить активные сессии.
* Проверить доверенные IP.
* Установить обновления безопасности.

### Ежемесячно

* Проверить резервные копии.
* Провести аудит доступов.
* Проверить подрядчиков.

### Ежеквартально

* Пересмотреть права доступа.
* Провести аудит безопасности.
* Проверить план реагирования на инциденты.

***

## Реагирование на инциденты

При подозрении на компрометацию:

1. Немедленно прекратите взаимодействие с подозрительным источником.
2. Завершите все активные сессии.
3. Смените пароли.
4. Проверьте журналы авторизации.
5. Перегенерируйте SSH-ключи при необходимости.
6. Ограничьте доступ к административным разделам.
7. Проверьте целостность файлов.
8. Проверьте резервные копии.
9. Зафиксируйте все признаки инцидента.
10. Усильте настройки безопасности.

***

## Заключение

Большинство успешных атак связано не с уязвимостями программного обеспечения, а с ошибками пользователей, социальной инженерией и неправильным управлением доступами.

Соблюдение требований данного документа позволит значительно снизить вероятность компрометации обменного пункта, потери данных и финансовых средств.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.iexexchanger.com/guide/nachalo-raboty/centr-bezopasnosti/operacionnaya-bezopasnost-opsec.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
