За какую безопасность платить сейчас, а какую можно отложить

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

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

Я обычно прошу отложить список и ответить на другой вопрос. Что самое плохое может сделать ваша система без участия человека. Не «какие у нас риски» вообще, а вполне конкретно. Какое действие она выполнит сама, если что-то пойдёт не так. Списать деньги? Удалить записи? Отправить письмо клиенту? Показать чужие данные? После этого вопроса список покупок обычно перестаёт выглядеть убедительным, потому что видно, что половина строк не касается ни одного из названных действий.

Список покупок вместо разговора о риске

Разница между двумя подходами простая, но её легко пропустить.

Список покупок отвечает на вопрос «сколько безопасности купить». Это вопрос без дна. На него всегда есть ответ «ещё немного», и он всегда стоит денег.

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

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

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

Дешёвые ограничения, которые ваша команда сделает за неделю

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

• Минимальные права. У агента должен быть доступ только к тем данным, которые нужны его сценарию. Не ко всей базе. Проверяется одним вопросом к разработчику. Под каким пользователем агент ходит в базу и что этот пользователь может. Если ответ «под тем же, что и приложение», значит, он может всё.
• Разделение доступов. Разные сценарии не должны пользоваться одним ключом с полными правами. Агент, который отвечает на письма, и агент, который формирует счета, это два разных набора прав. Когда один ключ обслуживает всё, любая проблема в одном месте открывает все остальные.
• Пределы на объём и частоту. Сколько строк можно выгрузить за одно обращение. Сколько обращений в минуту. На какую сумму операций в сутки. Предел не мешает нормальной работе и останавливает ненормальную. В одном продукте ограничение на выгрузку в тысячу строк поймало ошибку в коде на второй день после того, как его поставили. Без ограничения ошибка выгружала бы всю таблицу и никто бы этого не заметил.
• Журналы действий. Не логи приложения, а отдельная запись того, что агент прочитал, что вызвал и что отправил. Без этого вы никогда не узнаете, что именно случилось, и будете спорить с клиентом на уровне ощущений.
• Подтверждение опасных действий. Всё, что нельзя отменить, проходит через человека. Это одна проверка в коде, а не система.
• Ключи на сервере, а не в коде и не в браузере. Ключ в репозитории живёт вечно, даже если его оттуда удалили, потому что история коммитов помнит. Ключ во фронтенде доступен каждому.

Шесть пунктов. Ни один из них не требует покупки. Вместе они закрывают большую часть того, о чём вы будете жалеть.

Необратимое и чужие данные меняют весь расчёт

Есть две области, где рассуждение про «маленькой компании это рано» не работает вообще.

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

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

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

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

Что спокойно ждёт, а что нужно только большой компании

Теперь о том, на чём действительно можно сэкономить.

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

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

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

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

Универсальных сумм я не назову, и порогов по числу сотрудников тоже. У продукта с платежами и у продукта с публичными текстами расчёт разный при одинаковом размере команды. Соседний вопрос про то, где запускать модель, тоже влияет на этот расчёт, и он разобран отдельно в тексте о том, что место запуска меняет одни риски и не трогает другие.

Почему одно и то же решение стоит копейки сейчас и дорого через год

Некоторые вещи дешевеют от того, что их сделали рано. Точнее, они дорожают от того, что их отложили.

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

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

И так же ведут себя журналы. Записывать действия с первого дня почти ничего не стоит. Добавить запись в систему, которая работала два года без неё, значит пройти по всем местам вызова и ничего не забыть.

Есть и обратные примеры. Крупный инструмент, купленный через два года, обойдётся вам примерно так же, как обошёлся бы сегодня, а внедрять его вы будете с пониманием, которого сейчас нет.

Отложенная покупка почти ничего не теряет. Отложенное ограничение теряет много.

Когда пересчитать заново и кто подписывается под риском

Решение «пока не покупаем» правильное ровно до момента, когда меняются условия. Пересчитывать стоит в четырёх случаях.

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

Любое из этих событий это повод достать список заново, а не продолжать по инерции.

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

1. Что именно мы не делаем.
2. Что произойдёт, если это выстрелит.
3. Почему сейчас не делаем.
4. Когда вернёмся к вопросу и по какому событию.

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

Три ошибки, которые обходятся дороже любого инструмента

• Изображение безопасности вместо безопасности. Страница про защиту данных на сайте, галочка «согласен» в форме, политика на четыре экрана. Всё это может быть нужно, но ни одна из этих вещей не мешает агенту выгрузить базу. Признак ошибки простой. Спросите, какое конкретное действие системы предотвращает эта мера. Если ответа нет, мера работает на впечатление.
• «Ничего не трогаем до первого раунда». Логика понятна. Денег мало, а безопасность кажется дорогой. Только дешёвые меры не стоят дорого, они стоят недели работы своей команды. А через год они начнут стоить дорого, и как раз в тот момент, когда придёт клиент с требованиями и попросит показать, как у вас всё устроено.
• Покупка инструмента без понимания, какую проблему он решает. Это самая обидная ошибка, потому что она выглядит как ответственное поведение. Проверка одна. Попросите назвать конкретное событие в вашей системе, которое этот инструмент предотвратит или покажет. Не класс угроз, а событие. Если внятного ответа нет, покупка преждевременная.

Что сделать на этой неделе

Соберите разработчика и выпишите на один лист все действия, которые ваша система может выполнить без участия человека. Каждое действие одной строкой. Обычно получается от десяти до двадцати строк, и первое удивление наступает уже здесь, потому что часть из них вы не помните.

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

Строки, напротив которых стоит «ничего», и есть ваш бюджет на ближайший месяц. Скорее всего, он измеряется днями работы вашей команды, а не счётом от поставщика.

А когда кто-то в следующий раз принесёт список покупок, спросите, какую строку из вашего листа закрывает каждая позиция. Сколько строк останется без ответа?