Лекция «Безопасность и доступы в автоматизациях»

Около 50 минут на 14 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 38 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Четырнадцать тем меняют оптику: подключение в конструкторе — не настройка, а учётная запись, у которой есть владелец, права, место хранения секрета и срок жизни, и все четыре параметра задаются в момент нажатия кнопки. Разобрано, почему список подключений растёт без вашего участия и как выглядит реестр доступов из пяти колонок; как вебхук наследует права своего создателя и почему администратор, зашедший поправить чужой вебхук, молча становится его владельцем; три способа осиротеть, из которых чаще всего упускают третий — уход не владельца, а человека, который просто видел ключ. Отдельные темы про то, где на самом деле живёт секрет и почему история выполнений сценария оказывается незапланированной третьей копией клиентской базы у стороннего поставщика. На кейсах Zapier, Salesloft Drift и Internet Archive показано, что радиус поражения — единственная переменная, которой владеет клиент интеграции: утечку у поставщика предотвратить нельзя, а объём выносимого — можно. Центральный факт: выгруженные обращения в поддержку искали не ради содержания жалоб, а ради чужих ключей, оставленных в тексте. Скорость измерена: первое злоупотребление опубликованным ключом наступает через минуту, а в одной из кампаний атакующий работал через четыре минуты после того, как провайдер применил карантин. Закрывает лекцию порядок первого часа — отозвать, проверить перенаправления, заменить везде, прочитать логи, позвать ответственного за персональные данные — и список того, что реагированием не является: удаление сообщения, смена пароля человека и остановка сценария.

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

Нет, и обещать это было бы неправдой в двух местах сразу. Во-первых, лекция не выдаёт соответствия 152-ФЗ: соответствие собирают оператор и юрист, а настройщик сценариев отвечает за другой участок. Во-вторых, перечисленные меры не предотвращают утечку. В разобранном кейсе интеграции пострадали компании с сильными службами безопасности, и их клиенты не сделали ничего неправильного — утечка произошла у поставщика. Управлять можно радиусом поражения: тем, сколько данных и действий откроется, если ключ окажется у постороннего. Это скромнее, чем гарантия, и это единственное, что действительно в руках человека, собирающего сценарий. Отдельно отмечу, что здесь не разбираются протокол уведомления регулятора при утечке, трансграничная передача и карта составов ответственности — это соседние лекции плана.