Проверить безопасность интеграций
Результат страницы
Вы сможете принять решение разрешить, ограничить пилотом или отклонить до подключения сервиса. Итогом станет карточка интеграции: владелец, цель, данные, права, секреты, журналы, срок review и процедура отключения.
Интеграция не должна требовать пароль Upwork, cookie сессии, код MFA или вход от имени другого человека. Команда использует только официальный agency account и предусмотренные роли. Несколько личных аккаунтов, передача credentials и автоматизация через эмуляцию пользовательской сессии не являются допустимой архитектурой.
1. Опишите поток данных
Нарисуйте простой маршрут: источник → интеграция → получатель → хранилище → удаление. Для каждого шага укажите поля, цель, регион, срок хранения и владельца. Отдельно отметьте клиентские материалы, персональные данные, финансовую информацию и секреты.
Применяйте минимизацию: если напоминанию нужны deal_id, владелец и дата, не передавайте текст переписки и вложения. Не копируйте полную клиентскую базу «на будущее». Данные без понятной цели исключаются.
2. Проверьте способ подключения
Предпочитайте официальный API или OAuth с документированными scope. Проверьте актуальные правила платформы, лимиты и разрешённые способы использования. Не используйте scraping, обход ограничений, управление браузером через украденные или экспортированные cookie и неофициальные расширения, запрашивающие полный доступ.
Если официального способа нет, это не разрешение имитировать пользователя. Оставьте шаг ручным, запросите поддерживаемый вариант или откажитесь от интеграции.
3. Ограничьте права
Выдавайте минимальные scope, нужные для конкретного сценария. Разделяйте чтение и запись. Для теста используйте ограниченную среду и обезличенные данные. Доступ к финансам, контрактам, сообщениям и удалению не объединяйте в одном токене без подтверждённой необходимости.
У каждого пользователя отдельная учётная запись и MFA. Служебная учётная запись допустима только если сервис официально поддерживает такой тип, у неё есть владелец и она не маскирует действия людей.
4. Защитите секреты
API-ключи и токены хранятся в менеджере секретов или защищённой конфигурации, а не в документах, CRM, задачах, чатах и коде репозитория. Ограничьте доступ группой, задайте срок действия, где возможно, и подготовьте ротацию.
Не логируйте токены, пароли и содержимое чувствительных запросов. В webhook проверяйте подпись, время сообщения и защиту от повторной доставки. Используйте TLS и фиксируйте, кто может менять endpoint.
5. Оставьте контроль человеку
Автоматизируйте перенос статуса, напоминание или подготовку черновика. Критичные действия требуют явного подтверждения: отправка отклика, сообщение клиенту, цена, изменение scope или контракта, платёж, выдача доступа и удаление данных.
При использовании AI добавьте fact-check, минимизацию контекста и reviewer. Интеграция не должна автоматически публиковать сгенерированный текст или создавать вымышленные факты. Полная схема — в AI с контролем человека.
6. Проверьте поставщика
До пилота выясните:
- кто является обработчиком данных;
- где хранятся данные и резервные копии;
- используются ли данные для обучения;
- как устроены экспорт и окончательное удаление;
- есть ли журнал действий и уведомления об инцидентах;
- поддерживаются ли SSO, MFA и ролевой доступ;
- что произойдёт после отмены подписки;
- какие субподрядчики участвуют в обработке.
Ответ «мы безопасны» без конкретной документации недостаточен. Для чувствительных клиентских данных согласуйте применение с договором, NDA и требованиями клиента.
7. Подготовьте сбой и выход
Определите поведение при недоступности API, дубле события, частичной записи и истечении токена. Повтор операции должен быть безопасным, а ошибка — заметной владельцу. Нельзя оставлять внешнее действие в неопределённом состоянии.
Процедура выхода включает остановку jobs и webhooks, отзыв токенов, экспорт нужных данных, удаление копий, проверку резервов и уведомление владельцев процессов. Проверьте её во время пилота, а не после инцидента.
Решение preflight
Разрешить — цель ясна, способ официальный, права минимальны, критичные действия контролируются, выход проверен. Ограничить пилотом — остаётся один проверяемый риск. Отклонить — сервис требует credentials, непрозрачно хранит данные, не даёт отозвать доступ или зависит от unsafe automation.
Чеклист
- Есть владелец и деловая цель.
- Нарисован поток данных.
- Используется официальный API/OAuth.
- Проверены ToS и договоры клиента.
- Scope минимальны и разделены.
- Секреты находятся в защищённом хранилище.
- Включены MFA, журнал и уведомления.
- Критичные действия подтверждает человек.
- Нет credential-sharing, multi-account и обхода ограничений.
- Проверены сбой, отзыв, экспорт и удаление.
Следующий шаг
Запустите ограниченный пилот по процессу из страницы инструменты по стадии. Занесите одобренную интеграцию в реестр и назначьте повторный review после изменения прав, провайдера или потока данных.