Рекомендации по улучшению безопасности боевой среды

Не запускайте от учетной записи root. Для запуска StarVault используйте специальную непривилегированную сервисную учетную запись, а не учетную запись root или администратора. StarVault рассчитан на запуск от непривилегированного пользователя, и это значительно повышает защиту от различных атак с повышением привилегий.

Разрешите минимальные права на запись. Непривилегированная сервисная учетная запись StarVault не должна иметь доступа к перезаписи исполняемого двоичного файла или любых конфигурационных файлов StarVault. Пользователь StarVault может записывать только каталоги и файлы для локального хранилища StarVault (например, для бэкенда Integrated Storage) или логов аудита.

Сковзное шифрование TLS. В боевой среде StarVault всегда должен использоваться с TLS. Если для доступа к StarVault используются промежуточные балансировщики нагрузки или обратные прокси, необходимо использовать TLS для всех сетевых соединений между всеми компонентами системы (включая бэкенды хранилища), чтобы обеспечить шифрование всего трафика при передаче в StarVault и из него. По возможности следует установить заголовок HTTP Strict Transport Security (HSTS) с помощью функции пользовательских заголовков ответа StarVault.

Отключить подкачки. StarVault шифрует данные в процессе передачи и в состоянии покоя, однако для его работы конфиденциальные данные все равно должны находиться в памяти. Риск заражения должен быть сведен к минимуму путем отключения подкачки, чтобы операционная система не перемещала конфиденциальные данные на диск. Это особенно важно при использовании интегрированного бэкэнд-хранилища.

Отключите дампы ядра. Пользователь или администратор, который может принудительно выполнить дамп ядра и имеет доступ к полученному файлу, потенциально может получить доступ к ключам шифрования StarVault. Предотвращение дампов ядра зависит от конкретной платформы; в Linux установка ограничения ресурсов RLIMIT_CORE равным 0 отключает дампы ядра. В файле блока службы systemd установка LimitCORE=0 обеспечит выполнение этого параметра для службы StarVault.

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

Трафик файерволла. Используйте локальный брандмауэр или функции сетевой безопасности поставщика облачных услуг, чтобы ограничить входящий и исходящий трафик для StarVault и основных системных служб, таких как NTP. Это включает в себя ограничение входящего трафика разрешенными подсетями и исходящего трафика для служб, к которым StarVault необходимо подключиться, например баз данных.

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

Настройте блокировку пользователя. StarVault предоставляет функцию блокировки пользователей для методов аутентификации approle, ldap и userpass. Блокировка пользователей включена по умолчанию. Убедитесь, что порог блокировки и продолжительность блокировки соответствуют политике безопасности вашей организации.

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

Отключение истории команд оболочки. Возможно, вы захотите, чтобы сама команда starvault вообще не отображалась в истории.

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

Синхронизируйте часы. Используйте NTP или любой другой механизм, подходящий для вашей среды, чтобы убедиться, что все узлы StarVault согласны с тем, который сейчас час. StarVault использует часы для таких вещей, как обеспечение TTL и установка дат в сертификатах PKI, и если узлы имеют значительную разницу во времени - это может привести к ошибкам.

Ограничение доступа к хранилищу. StarVault шифрует все данные в состоянии покоя, независимо от того, какой бэкэнд для хранения используется. Несмотря на то что данные зашифрованы, злоумышленник с произвольным контролем может привести к повреждению или потере данных, изменив или удалив ключи. Во избежание несанкционированного доступа или операций - доступ к внутреннему хранилищу должен быть ограничен только StarVault.

Никаких учетных данных с открытым текстом. Блок seal в файле конфигурации StarVault настраивает тип печати для дополнительной защиты данных, например с помощью облачных KMS-решений для шифрования и расшифровки корневого ключа (также известного как мастер-ключ). НЕ храните учетные данные облака открытым текстом в блоке seal. Если сервер StarVault размещен на той же облачной платформе, что и служба KMS, используйте идентификационные решения для конкретной платформы. Например:

Используйте самые безопасные из доступных алгоритмов. Слушатель TLS в StarVault поддерживает различные устаревшие алгоритмы для обратной совместимости. Хотя эти алгоритмы доступны, их не рекомендуется использовать, особенно если имеется альтернатива лучше. Если возможно, использование TLS 1.3 обеспечивает применение современных алгоритмов шифрования для шифрования данных при передаче и обеспечения секретности при пересылке.

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

Недетерминированное слияние файлов. Объединение конфигурационных файлов StarVault происходит недетерминированно, и несоответствие настроек в разных файлах может привести к несоответствию настроек StarVault. Убедитесь, что конфигурации наборов согласованы во всех файлах (и в любых объединенных файлах, обозначенных командой -config).

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

Используйте стандартный ввод для секретов StarVault. StarVault login и StarVault unseal позволяют операторам предоставлять секретные значения как из стандартного ввода, так и из аргументов командной строки. Аргументы командной строки могут быть прочитаны другими непривилегированными пользователями на том же хосте или сохранены в истории оболочки.

Вопросы, связанные с увольнением. Удаление учетных записей в StarVault или связанных с ними поставщиков идентификационных данных может не сразу отменить доступ на основе токенов. В зависимости от того, как управляется доступ к StarVault, операторы должны рассмотреть следующие варианты:

Используйте короткие TTL. По возможности, учетные данные, выдаваемые StarVault (например, токены, сертификаты x.509), должны быть недолговечными, чтобы защитить их от возможной компрометации и уменьшить необходимость использования методов отзыва.

Отключите SSH/удаленный рабочий стол. При запуске StarVault как приложения с одним арендатором - пользователи никогда не должны получать доступ к машине напрямую. Вместо этого они должны обращаться к StarVault через API по сети. Для отладки используйте централизованное решение для ведения логов и телеметрии. Обязательно ограничьте доступ к логам по мере необходимости.

Использование функций безопасности systemd. Systemd предоставляет ряд функций, которые можно использовать для блокировки доступа к файловой системе и административным возможностям. Файл сервисных блоков, поставляемый с официальными пакетами StarVault Linux, устанавливает некоторые из них по умолчанию, в том числе:

ProtectSystem=full
PrivateTmp=yes
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
AmbientCapabilities=CAP_IPC_LOCK
ProtectHome=read-only
PrivateDevices=yes
NoNewPrivileges=yes

Неизменяемые обновления. StarVault полагается на внешнее хранилище для сохранения данных. Такое разделение позволяет управлять серверами, на которых работает StarVault, без изменений. При обновлении до новых версий в сеть включаются новые сервера с обновленной версией StarVault. Они подключаются к тому же бэкенду общего хранилища и снимают печать. Затем старые серверы удаляются. Это снижает необходимость в удаленном доступе и оркестровке обновлений, которые могут внести бреши в систему безопасности.

Настройте SELinux/AppArmor. Использование дополнительных механизмов, таких как SELinux и AppArmor, поможет обеспечить дополнительные уровни безопасности при использовании StarVault.

Измените пределы. Возможно, в вашем дистрибутиве Linux установлены строгие ограничения (ulimits) на количество процессов. Перед запуском в боевой среде просмотрите ulimits на максимальное количество открытых файлов, соединений и т.д.; возможно, их нужно увеличить.

Контейнеры Docker. Чтобы задействовать функцию "блокировки памяти" в контейнере StarVault, вам, скорее всего, потребуется использовать overlayfs2 или другой поддерживаемый драйвер.