Безопасность¶

Введение ¶

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

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

Области, вызывающие беспокойство ¶

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

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

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

Другими словами, слепо доверять брандмауэру тоже не стоит.

Если ваш брокер поддерживает тонкий контроль доступа, как, например, RabbitMQ, то вам следует рассмотреть возможность его включения. Смотрите, например, http://www.rabbitmq.com/access-control.html.

Если поддерживается бэкендом брокера, вы можете включить сквозное SSL-шифрование и аутентификацию, используя broker_use_ssl.

Клиент ¶

В Celery «клиент» относится ко всему, что посылает сообщения брокеру, например, веб-серверы, которые применяют задания.

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

[Здесь нужно больше текста]

Рабочий ¶

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

Исключением из этого правила является использование многопроцессорного пула задач, который в настоящее время используется по умолчанию. В этом случае задача будет иметь доступ к любой памяти, скопированной в результате вызова fork(), и доступ к содержимому памяти, записанному родительскими задачами в том же дочернем рабочем процессе.

Ограничить доступ к содержимому памяти можно, запустив каждую задачу в подпроцессе (fork() + execve()).

Ограничение доступа к файловой системе и устройствам может быть выполнено с помощью chroot, jail, sandboxing, виртуальных машин или других механизмов, предусмотренных платформой или дополнительным программным обеспечением.

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

Сериализаторы ¶

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

Сериализатор pickle удобен тем, что может сериализовать практически любой объект Python, даже функции, но по тем же причинам pickle по своей сути небезопасен [*], и его следует избегать, когда клиенты не доверяют или не аутентифицированы.

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

Добавлено в версии 3.0.18.

Примечание

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

accept_content = ['json']

Он принимает список имен сериализаторов и типов содержимого, поэтому вы также можете указать тип содержимого для json:

accept_content = ['application/json']

Celery также поставляется со специальным сериализатором auth, который проверяет связь между клиентами Celery и рабочими, убеждаясь, что сообщения приходят из надежных источников. Используя Public-key cryptography, сериализатор auth может проверять подлинность отправителей, чтобы включить эту функцию, прочитайте Подписание сообщений для получения дополнительной информации.

Подписание сообщений ¶

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

Оптимально сертификаты должны быть подписаны официальным лицом Certificate Authority, но они могут быть и самоподписанными.

Чтобы включить это, необходимо настроить параметр task_serializer на использование сериализатора auth. Чтобы заставить рабочих принимать только подписанные сообщения, следует установить accept_content в [„auth“]. Для дополнительной подписи протокола событий установите event_serializer в auth. Также необходимо настроить пути, используемые для нахождения закрытых ключей и сертификатов в файловой системе: параметры security_key, << 2 >>> и << 3 >>> соответственно. Алгоритм подписи можно настроить с помощью параметра security_certificate.

С этими настройками также необходимо вызвать функцию celery.setup_security(). Обратите внимание, что это также отключит все небезопасные сериализаторы, так что рабочий не будет принимать сообщения с ненадежными типами содержимого.

Это пример конфигурации с использованием сериализатора auth, с файлами закрытого ключа и сертификата, расположенными в /etc/ssl.

app = Celery()
app.conf.update(
    security_key='/etc/ssl/private/worker.key'
    security_certificate='/etc/ssl/certs/worker.pem'
    security_cert_store='/etc/ssl/certs/*.pem',
    security_digest='sha256',
    task_serializer='auth',
    event_serializer='auth',
    accept_content=['auth']
)
app.setup_security()

Примечание

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

Также обратите внимание, что сериализатор auth не будет шифровать содержимое сообщения, поэтому при необходимости это нужно будет включить отдельно.

Обнаружение вторжений ¶

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

Журналы ¶

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

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

Это должно быть довольно просто настроить с помощью syslog (см. также syslog-ng и << 1 >>>). Celery использует библиотеку rsyslog и уже имеет поддержку использования syslog.

Совет для параноиков - отправлять журналы с помощью UDP и перерезать передающую часть сетевого кабеля сервера регистрации :-)

Tripwire ¶

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

Некоторые реализации с открытым исходным кодом включают:

Кроме того, файловая система ZFS поставляется со встроенными проверками целостности, которые можно использовать.

Сноски

Руководство по мониторингу и управлению

Оптимизация