> 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)

Операционная безопасность — это правила работы с сервером, учётными записями, устройствами и другими системами, от которых зависит обменный пункт.

Даже правильно настроенный iEXExchanger не защищает от ситуации, когда злоумышленник получил доступ к электронной почте владельца, Cloudflare, регистратору домена, Telegram, GitHub, серверу или платёжной системе.

Поэтому безопасность обменного пункта необходимо рассматривать целиком.

К критически важным системам относятся:

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

Рекомендации этой страницы основаны на подходах NIST Cybersecurity Framework 2.0, ISO/IEC 27001 и CIS Controls v8.1. NIST CSF 2.0 рассматривает безопасность как непрерывный процесс из шести основных функций: Govern, Identify, Protect, Detect, Respond и Recover.

## Основной принцип

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

Используйте несколько уровней защиты:

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

CIS Controls отдельно выделяет управление учётными записями и управление правами доступа: доступ необходимо выдавать, изменять и отзывать в соответствии с реальной необходимостью пользователя.

## Минимальная защита перед запуском

До начала работы production-проекта рекомендуется проверить как минимум следующие пункты:

* включена 2FA для административной панели iEXExchanger;
* включена MFA для электронной почты;
* защищён аккаунт регистратора домена;
* защищён Cloudflare;
* защищён GitHub;
* включена Two-Step Verification в Telegram;
* сервер использует SSH-ключи;
* PostgreSQL и Redis не доступны напрямую из интернета;
* сотрудники используют отдельные учётные записи;
* права сотрудников ограничены их задачами;
* настроены резервные копии;
* резервная копия хранится отдельно от production-сервера;
* настроен контроль входов и активных сессий;
* программное обеспечение сервера и рабочих устройств регулярно обновляется.

## Управление доступом

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

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

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

Индивидуальные учётные записи позволяют:

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

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

### Минимальные права

Пользователю выдаются только те права, которые необходимы для его работы.

Например, оператору, который работает только с заявками, не требуется доступ к серверу, Cloudflare, GitHub или настройкам безопасности.

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

### Отдельные административные аккаунты

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

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

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

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

Не передавайте подрядчику собственный основной аккаунт.

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

Если использовались временные SSH-ключи, API-токены или другие ключи доступа, после завершения работ их также необходимо удалить.

## Пароли

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

Не используйте один пароль одновременно для:

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

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

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

Для административных аккаунтов iEXExchanger рекомендуется использовать длинные уникальные пароли, которые не применяются ни в одном другом сервисе.

Не храните пароли:

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

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

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

Включайте MFA для:

* административной панели iEXExchanger;
* электронной почты;
* Cloudflare;
* GitHub;
* регистратора домена;
* платёжных систем;
* других сервисов, связанных с управлением проектом.

CISA рекомендует использовать MFA и, где это возможно, переходить на устойчивые к фишингу способы аутентификации, например FIDO/WebAuthn.

При наличии выбора предпочтение можно отдавать:

* passkey;
* аппаратному ключу безопасности;
* приложению-аутентификатору.

SMS лучше не использовать как единственный дополнительный фактор, если сервис поддерживает более надёжный способ.

### Резервные коды

После включения MFA сервис может предоставить recovery-коды или backup-коды.

Сохраните их отдельно от основного рабочего устройства.

Не храните единственную копию recovery-кодов:

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

Cloudflare, например, предоставляет отдельные backup-коды для восстановления доступа при потере основного устройства или ключа.

## Встроенная защита iEXExchanger

iEXExchanger предоставляет собственные механизмы защиты административной части. Их необходимо использовать вместе с защитой сервера и внешних аккаунтов.

### Двухфакторная аутентификация

Для доступа к административной панели можно использовать двухфакторную аутентификацию через Google Authenticator.

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

2FA рекомендуется включить для всех пользователей, имеющих административный доступ.

### Ограничение доступа по IP

iEXExchanger позволяет ограничивать авторизацию в административной панели списком разрешённых IP-адресов.

Такую защиту рекомендуется использовать для владельцев и ключевых администраторов со статическими или контролируемыми IP-адресами.

Перед включением убедитесь, что у вас останется рабочий способ доступа к панели.

### Адрес административной панели

iEXExchanger позволяет использовать собственный путь административной панели вместо стандартного значения.

Уникальный адрес не заменяет пароль, 2FA и контроль доступа, но уменьшает количество автоматических обращений к стандартному административному URL.

Не публикуйте административный адрес в открытых источниках.

### CSP

В iEXExchanger предусмотрена поддержка Content Security Policy. CSP используется как дополнительный уровень защиты браузера от загрузки и выполнения нежелательного контента.

Используйте актуальную настройку CSP, предусмотренную документацией установленной версии iEXExchanger.

### Обновления

Регулярно устанавливайте актуальные версии iEXExchanger и связанные исправления безопасности.

Не оставляйте production-проект на устаревшей версии без причины. Официальная документация iEXExchanger также рекомендует своевременно устанавливать новые версии как часть общей защиты проекта.

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

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

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

### SSH

Для административного доступа используйте SSH-ключи.

После проверки входа по ключу рекомендуется отключить парольную SSH-аутентификацию, если используемая инфраструктура позволяет работать без неё.

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

Не передавайте один приватный SSH-ключ нескольким сотрудникам.

{% hint style="warning" %}
Не отключайте существующий способ доступа к серверу, пока не проверили новый SSH-ключ и возможность восстановления доступа через консоль или rescue-режим хостинг-провайдера.
{% endhint %}

По возможности используйте отдельного системного пользователя с `sudo` вместо постоянной ежедневной работы непосредственно под `root`.

Изменение стандартного SSH-порта можно использовать для уменьшения количества автоматических попыток подключения, но оно не заменяет SSH-ключи, firewall и правильное управление доступом.

### Firewall

Открывайте во внешний интернет только те порты и сервисы, которые действительно используются.

PostgreSQL и Redis не должны быть публично доступны, если для конкретной архитектуры это отдельно не требуется.

Внешний доступ к административным и системным сервисам лучше ограничивать по IP, VPN или другим средствам контроля.

### Обновления системы

Регулярно устанавливайте исправления безопасности операционной системы и серверного программного обеспечения.

Для production-сервера обновления лучше выполнять контролируемо: предварительно создайте резервную копию, проверьте изменения и только затем обновляйте критические компоненты.

### Fail2Ban

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

Он не заменяет SSH-ключи, ограничение доступа и firewall.

### Production и тестирование

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

Для разработки и экспериментов лучше использовать отдельное окружение.

## Секреты и конфигурация

К секретным данным относятся:

* пароли;
* API-ключи;
* приватные ключи;
* SSH-ключи;
* токены;
* ключи платёжных систем;
* seed-фразы;
* recovery-коды;
* конфигурационные значения с доступом к инфраструктуре.

Не отправляйте такие данные в Telegram, обычных чатах или задачах подрядчикам без необходимости.

Не добавляйте `.env`, приватные ключи и production-секреты в Git-репозитории.

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

## Домен и DNS

Домен является критической частью инфраструктуры.

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

Для аккаунта регистратора:

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

Registrar Lock предназначен для защиты от несанкционированного переноса домена. Для особо критичных доменов некоторые регистраторы также предоставляют Registry Lock.

Не передавайте основной аккаунт регистратора подрядчикам только для настройки DNS. Если сервис позволяет выдавать ограниченный доступ, используйте его.

## Cloudflare

Cloudflare находится между пользователем и сервером, поэтому доступ к аккаунту Cloudflare необходимо защищать так же тщательно, как доступ к серверу.

### Защита аккаунта

Включите 2FA.

Если доступна аппаратная security key или другой более устойчивый способ аутентификации, используйте его для ключевых административных аккаунтов. Cloudflare поддерживает TOTP и аппаратные ключи безопасности для 2FA.

Сохраните backup-коды в защищённом месте.

### Защита origin-сервера

Если сайт работает через Cloudflare, недостаточно просто включить проксирование DNS.

По возможности ограничьте прямой доступ к origin-серверу. Cloudflare рекомендует различные варианты защиты origin, включая Cloudflare Tunnel, Authenticated Origin Pulls и ограничение входящего трафика адресами Cloudflare.

Не публикуйте реальный IP production-сервера без необходимости.

### WAF и Rate Limiting

Используйте WAF и Rate Limiting для чувствительных точек приложения, где это требуется.

Rate Limiting может ограничивать количество запросов к определённым URL и используется, например, для защиты авторизации и API от автоматизированного злоупотребления.

Правила должны соответствовать реальному трафику проекта. Слишком жёсткие ограничения могут блокировать обычных клиентов.

### DDoS

Cloudflare можно использовать как внешний уровень защиты от DDoS-атак. В документации iEXExchanger также предусмотрены отдельные инструкции по подключению и работе с Cloudflare.

Режим Under Attack используйте при необходимости, а не как постоянную замену нормальной настройки WAF и Rate Limiting.

## Электронная почта

Электронная почта часто используется для восстановления других аккаунтов, поэтому её компрометация может привести к потере доступа сразу к нескольким системам.

Для административной почты:

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

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

### SPF, DKIM и DMARC

Если с домена обменного пункта отправляется электронная почта, настройте SPF, DKIM и DMARC.

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

## Фишинг и социальная инженерия

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

Особенно внимательно относитесь к сообщениям с просьбой:

* срочно предоставить доступ к серверу;
* отправить резервную копию;
* передать API-ключ;
* передать recovery-код;
* изменить реквизиты;
* установить программу;
* открыть архив;
* выполнить неизвестную команду;
* авторизоваться по присланной ссылке.

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

Не используйте номер телефона, Telegram-аккаунт, электронную почту или ссылку, которые были присланы внутри самого подозрительного сообщения, как единственный способ проверки его подлинности.

## Telegram

Для рабочего Telegram включите **Two-Step Verification**.

Telegram также позволяет просматривать активные устройства и завершать неизвестные сессии. Эти функции находятся в настройках безопасности аккаунта.

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

* установить пароль Two-Step Verification;
* указать защищённую recovery-почту;
* установить локальный код блокировки приложения;
* периодически проверять список устройств;
* завершать незнакомые сессии.

Никогда не передавайте другим лицам:

* код входа Telegram;
* пароль Two-Step Verification;
* recovery-коды других сервисов;
* seed-фразы;
* приватные ключи;
* SSH-ключи.

Telegram не должен использоваться как постоянное хранилище секретов проекта.

## GitHub

Если GitHub используется для хранения или обновления проекта, компрометация аккаунта может дать злоумышленнику доступ к исходному коду, процессу развёртывания или связанным секретам.

### Защита аккаунта

Включите 2FA.

GitHub также поддерживает passkeys, которые могут использоваться для безопасной авторизации и удовлетворять требованиям пароля и 2FA.

Сохраните методы восстановления доступа отдельно.

### Доступ к репозиториям

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

После завершения работы сотрудника или подрядчика удалите его доступ.

Периодически проверяйте Deploy Keys.

### API-токены

При необходимости использовать Personal Access Token выдавайте ему только необходимые разрешения и ограничивайте срок действия.

GitHub рекомендует по возможности использовать fine-grained personal access tokens и предоставлять минимальные необходимые разрешения.

### Секреты в репозитории

Не храните в GitHub:

* `.env` production;
* приватные SSH-ключи;
* ключи платёжных систем;
* seed-фразы;
* пароли баз данных;
* production API-токены.

Если используемый тариф и тип репозитория поддерживают Secret Scanning и Push Protection, включите их. Push Protection предназначен для обнаружения и блокирования попыток отправить поддерживаемые секреты в репозиторий.

## Платёжные системы

Аккаунты платёжных систем имеют непосредственный доступ к средствам, поэтому для них необходимо использовать максимально доступную защиту.

По возможности включайте:

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

Официальная документация iEXExchanger также рекомендует включать доступные механизмы подтверждения и ограничения доступа для подключаемых платёжных систем.

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

## Криптовалютные кошельки

Не храните все средства проекта в кошельке, который постоянно подключён к автоматическим операциям.

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

Seed-фразы и приватные ключи:

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

Seed-фраза не должна входить в обычную резервную копию сайта вместе с файлами приложения и базой данных.

Для неё требуется отдельный защищённый способ хранения.

## Автоматические выплаты

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

Если используются автовыплаты:

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

В iEXExchanger предусмотрена дополнительная защита кодом безопасности для сценариев автоматических выплат.

## Рабочие устройства

Компрометация компьютера администратора может сделать бессмысленной защиту остальных систем.

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

Для устройств владельца и администраторов рекомендуется:

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

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

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

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

Перед предоставлением доступа подрядчику определите, что именно ему требуется.

Не выдавайте полный доступ «на всякий случай».

### Перед началом работ

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

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

1. Отключите созданную учётную запись.
2. Удалите SSH-ключ подрядчика.
3. Отзовите временные API-токены.
4. Удалите доступ к GitHub.
5. Удалите доступ к Cloudflare и другим сервисам.
6. Проверьте журналы действий.
7. Если подрядчику были известны общие секреты, замените их.

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

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

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

Рекомендуется использовать принцип 3-2-1:

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

Такой подход используется и в рекомендациях CISA по резервному копированию.

Для iEXExchanger резервному копированию в первую очередь подлежат:

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

Recovery-коды MFA можно хранить отдельно как часть аварийного комплекта доступа, но не следует помещать их вместе с обычным backup сайта.

Seed-фразы и приватные ключи кошельков также должны храниться отдельно.

### Проверка резервных копий

Наличие backup-файла ещё не означает, что проект можно восстановить.

Периодически проверяйте:

* создаются ли новые копии;
* доступны ли они;
* не повреждены ли архивы;
* можно ли восстановить базу данных;
* есть ли отдельная копия вне production-сервера.

CIS Control 11 отдельно рассматривает возможность восстановления данных до доверенного состояния после инцидента.

## Что проверять регулярно

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

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

### Постоянно

Следите за уведомлениями о:

* новых входах;
* изменении пароля;
* отключении MFA;
* добавлении нового устройства;
* изменении DNS;
* изменении настроек домена;
* создании новых API-токенов;
* подозрительных финансовых операциях.

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

Проверяйте:

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

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

Проверяйте:

* список сотрудников с доступом;
* аккаунты бывших сотрудников и подрядчиков;
* SSH-ключи;
* GitHub Deploy Keys;
* API-токены;
* Cloudflare;
* резервные копии;
* свободное место и состояние сервера.

### Периодически

Проводите полную проверку того, сможете ли вы восстановить управление проектом при потере:

* основного телефона;
* рабочего компьютера;
* доступа к электронной почте;
* Cloudflare;
* сервера.

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

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

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

Сначала ограничьте возможный ущерб.

### Ограничение доступа

В зависимости от характера инцидента:

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

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

### Смена доступов

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

Используйте заведомо доверенное устройство.

В первую очередь защищайте аккаунты, через которые можно восстановить остальные:

1. электронную почту;
2. менеджер паролей;
3. регистратора домена;
4. Cloudflare;
5. сервер;
6. GitHub;
7. административную панель;
8. платёжные системы.

Затем:

* смените скомпрометированные пароли;
* отзовите активные сессии;
* замените SSH-ключи;
* замените API-токены;
* замените другие секреты, которые могли быть получены злоумышленником.

### Проверка сервера

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

* новые системные учётные записи;
* SSH-ключи;
* `authorized_keys`;
* запущенные процессы;
* задания cron;
* системные службы;
* изменённые файлы проекта;
* неизвестные приложения;
* сетевые подключения;
* журналы входов.

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

### Проверка внешних сервисов

Проверьте:

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

Обращайте внимание на новые устройства, неизвестные ключи, изменённые настройки, правила переадресации почты и созданные токены.

### Возврат проекта в работу

Возвращайте обменный пункт из режима обслуживания только после того, как:

* источник инцидента устранён;
* критические доступы заменены;
* неизвестные сессии отключены;
* сервер проверен или восстановлен;
* DNS и Cloudflare находятся под вашим контролем;
* платёжные системы проверены;
* работа Frontend и Backend проверена;
* резервные копии доступны.

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

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

Перед запуском production-проекта убедитесь, что:

* для административной панели iEXExchanger включена 2FA;
* административный доступ ограничен по IP там, где это возможно;
* используется собственный адрес административной панели;
* сотрудникам выданы только необходимые права;
* у каждого сотрудника отдельная учётная запись;
* для критических сервисов используются уникальные пароли;
* используется менеджер паролей;
* включена MFA для электронной почты;
* включена MFA для регистратора домена;
* включена MFA для Cloudflare;
* включена 2FA или passkey для GitHub;
* включена Two-Step Verification в Telegram;
* сохранены recovery-коды;
* SSH работает через индивидуальные ключи;
* лишние серверные порты закрыты;
* PostgreSQL и Redis не открыты в интернет;
* production-секреты отсутствуют в GitHub;
* доступы бывших сотрудников и подрядчиков удалены;
* настроены резервные копии;
* существует копия вне production-сервера;
* восстановление из резервной копии проверялось;
* рабочие устройства защищены и обновляются;
* известен порядок действий при компрометации.

Безопасность обменного пункта зависит не от одной настройки, а от всей цепочки: устройства владельца, учётных записей, сервера, домена, Cloudflare, iEXExchanger, платёжных систем и резервных копий. Компрометация любого критического элемента должна быть ограничена другими уровнями защиты.