130 lines
11 KiB
Markdown
130 lines
11 KiB
Markdown
# Концепция обеспечения информационной безопасности
|
||
## 1. Защита инфраструктуры
|
||
### 1.1. Физическая защита компонентов
|
||
Серверные компоненты размещаются в центре обработки данных DataPro, который обеспечивает физическую безопасность.
|
||
ЦОД сертифицирован по уровню TIER III и соответствует стандартам:
|
||
|
||
- PCI Data Security 3.2.1
|
||
- ISO/IEC 27001:2013
|
||
- ISO/IEC 20000-1:2011
|
||
- ISO 9001:2015
|
||
|
||
### 1.2. Используемое программное обеспечение
|
||
Приложение реализуется за счёт использования открытого программного обеспечения.
|
||
Все серверы работают на операционной системе OpenBSD.
|
||
В качестве системы управления базой данных используется PostgreSQL.
|
||
Обратный прокси-сервер реализован с помощью nginx с подключенным модулем naxsi.
|
||
Приложение работает с использованием Python.
|
||
|
||
### 1.3. Виртуализация
|
||
Для изоляции компонентов применяется виртуализация, реализуемая встроенным в OpenBSD демоном vmd.
|
||
|
||
Применение виртуализации позволяет отделить среды исполнения и обеспечить переносимость виртуальных серверов между физическими серверами.
|
||
|
||
### 1.4. Управление
|
||
Управление инфраструктурой осуществляется централизовано с помощью ПО ansible.
|
||
|
||
## 2. Управление доступом
|
||
|
||
### 2.1. Идентификация
|
||
В качестве идентификаторов пользователей системы используются email адреса.
|
||
В качестве идентификаторов посетителей могут использововаться email, номер телефона, аккаунт в социальной сети.
|
||
Токены, назначаемые пользователю, используются только для проведения идентификации и аутентификации и далее не используются в авторизации.
|
||
|
||
### 2.2. Аутентификация
|
||
Аутентификация осуществляется на сервере приложений.
|
||
Для аутентификации может использоваться проверка пароля, JWT, Magic-Link, U2F.
|
||
После выполнения аутентификации идентификатор вместе с ролью и атрибутами пользователя передаётся в систему авторизации.
|
||
|
||
### 2.3. Авторизация
|
||
Авторизация осуществляется в БД.
|
||
Разграничение доступа к отдельным данным выполняется с помощью Row Level Security.
|
||
Для управления доступом применяются роли и политики.
|
||
Роль пользователя определяет какая политика разграничения доступа должна применяться, а политика определяет необходимые атрибуты пользователя и данных для предоставления доступа.
|
||
|
||
## 3. Ограничения программной среды
|
||
|
||
### 3.1. Разделение компонентов
|
||
Для обеспечения изоляции программного обеспечения с разным уровнем доверия выделяются следующие компоненты:
|
||
|
||
1. Прокси-сервер
|
||
2. Сервер приложений
|
||
3. База данных
|
||
|
||
#### 3.1.1. Прокси-сервер
|
||
Прокси-сервер принимает внешние соединения от пользователей и переадресует их серверу приложений.
|
||
Прокси-сервером реализуется базовая фильтрация и балансировка HTTP соединений.
|
||
|
||
#### 3.1.2. Сервер приложений
|
||
Сервер приложений принимает соединения только от прокси-сервера и осуществляет обработку запросов.
|
||
Сервер приложений недоступен из Интернета для прямых соединений.
|
||
|
||
#### 3.1.3. База данных
|
||
База данных принимает соединения только от сервера приложений и администраторов системы.
|
||
База данных недоступна из Интернета для прямых соединений.
|
||
|
||
### 3.2. Разделение водоёмов данных
|
||
Данные, принадлежащие различным заказчикам, находятся в отдельных независимых друг от друга базах данных или схемах (в зависимости от версии серверного ПО).
|
||
|
||
### 3.3. Ограничения возможностей приложений
|
||
Для ограничения возможностей программного кода сервера приложений планируется применять механизмы защиты pledge и unveil, реализованные в OpenBSD.
|
||
|
||
```sh
|
||
man 2 pldge
|
||
man 2 unveil
|
||
```
|
||
|
||
### 3.4. Отключение неиспользуемого ПО
|
||
На серверах системы строго отслеживается используемое программное обеспечение и минимизируется их количество до минимального необходимого для функционирования компонента.
|
||
|
||
## 4. Противодействие несанкционированному воздействию
|
||
|
||
### 4.1. Регистрация событий безопасности
|
||
События безопасности сохраняются в системный журнал каждого сервера, а также пересылаются в центральный сервер сбора событий безопасности для централизованной обработки.
|
||
|
||
### 4.2. Обнаружение вторжений
|
||
Осуществляется переодическое исследование событий безопасности для выявления возможных вторжений.
|
||
|
||
### 4.3. Межсетевое экранирование
|
||
На используемых физических серверах используется пакетный фильтр (PF) для открытия только необходимых входящих соединений.
|
||
|
||
Пакетный фильтр применяется для всего трафика, включая трафик между виртуальными серверами.
|
||
|
||
### 4.4. Шифрование
|
||
Трафик между конечным пользователем и системой обязательно шифруется криптоусточивыми алгоритмами.
|
||
|
||
Запрещены подключения внешних пользователей к системе, а также системы к внешним сервисам через нешифрованные соединения.
|
||
|
||
## 5. Отказоустойчивость
|
||
|
||
### 5.1. Резервное копирование
|
||
Резервное копирование осуществляется в соответствии с регламентом резервного копирования.
|
||
Резервные копии хранятся на отдельном сервере в зашифрованном виде.
|
||
Ключ шифрации данных доступен только инициатору резервного копирования и неизвестен для сервера бекапов.
|
||
|
||
### 5.2. Избыточность компонентов
|
||
Компоненты, требующие соблюдения высокой доступности, могут дублироваться.
|
||
|
||
### 5.3. Аварийное восстановление
|
||
Аварийное восстановление компонентов возможно из резервных копий, а также переключением на запасной компонент, при использовании дублирования.
|
||
|
||
## 6. Безопасная разработка
|
||
### 6.1. VCS
|
||
Для разработки используется система управления версиями программного обеспечения.
|
||
Каждый релиз отмечается версией.
|
||
В систему контроля версиями ПО записываются любые изменения в программном коде с указанием автора.
|
||
Модификация зафиксированного кода не допускается.
|
||
|
||
Импорт кода осуществляется только для подписанного кода.
|
||
|
||
### 6.2. Учёт обращений
|
||
Все обращения пользователей, идентифицированные ошибки и проблемы безопасности фиксируются в системе управления разработкой через назначение тикета и отслеживание активностей, связанных с тикетом.
|
||
|
||
### 6.3. Тесты
|
||
По возможности используется методика разработки через тестирование TDD.
|
||
Программное обеспечение по возможности покрывается тестами, проверяющие нормальную и ошибочную работу приложения.
|
||
|
||
Тесты используются не только для ПО приложения, но и для структуры базы данных.
|
||
|
||
Тесты позволяют установить контракт (порядок работы) программного обеспечения и отслеживать не соответствующее контракту поведение ПО.
|