Ваш ключ VPN доступен всем: что нужно исправить

Первый признак — обычно предупреждение, а не сбой. Клиент отказывается загрузить ключ, потому что файл доступен на чтение группе или всем, или проверка безопасности находит client.key с режимом 644 в каталоге профиля, где также лежат экспортированные пакеты. Пока ничего не сломалось, и именно поэтому предупреждение игнорируют. Ключ работает, туннель поднимается, а файл может прочитать любая учётная запись на машине.

Симптом — предупреждение о правах, а не отказ

В Unix-подобной системе приватный ключ должен быть доступен только учётной записи, запускающей службу. Режим 600 с правильным владельцем — обычная практика. Режим 644 означает, что любой локальный пользователь может скопировать ключ, а на общем сборочном хосте это реальная аудитория.

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

Приведите режим в соответствие с идентичностью службы

Доступ только для владельца подходит для ключа, которым пользуется этот владелец. Службе с намеренно общей группой может понадобиться другая контролируемая схема, например чтение группой ключа, принадлежащего служебной учётной записи. Слепая установка одного числового режима для всех файлов ломает поддерживаемых клиентов, а chmod -R 777 не решает ничего.

Проверьте владельца и служебную учётную запись, прежде чем что-либо менять. Публичные сертификаты CA и приватные ключи идентичности имеют разные требования к секретности, даже если лежат в одном каталоге, поэтому рекурсивный режим на всю папку обращается с ними как с одним объектом.

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

На других платформах используйте документированное хранилище ключей или модель управления доступом, а не переводите Unix-режимы в догадку. Имя файла, оканчивающееся на private, — это метка, а не механизм принуждения.

Найдите копии, которые не охватывает режим

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

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

Ищите копии, прежде чем объявить работу выполненной: grep -rl строку заголовка ключа в вероятных каталогах и взгляд на исключения резервного копирования. Результат обычно интереснее файла, с которого вы начали.

После исправления проверьте и замените

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

Если ключ был раскрыт, ужесточите режим, затем замените учётные данные и отзовите старые. Спецификация POSIX chmod объясняет, что означает каждый бит режима, и это стоит знать до того, как следующая проверка попросит вас обосновать выбранное число.