Иллюзия безопасности вашего интернет-проекта, господин клиент!

Сибирь. Середина октября. Лужи уже покрывались коркой. Мне предстояло ехать в Новосибирск, затем в тот же день вернуться в Барнаул, отоспаться, подготовить слайды по докладу о безопасности и затем сразу лететь в Москву на большую IT-конференцию. Докладчиком. Я мало что мог рассказать о безопасности, кроме только что пережитого д..рьмового опыта. Больше о человеческой жадности и глупости, нежели о технологиях.

«Х..йня, прорвемся», — решил я, запустил скайп и принялся методично обзванивать своих знакомых. Директоров студий. Я специально просил включить видео (и включал его сам), глаза-в-глаза, две минуты, один вопрос. Грустные, отведенные в сторону взгляды были мне ответом. Что же, уже неплохо.

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

Три часа пустой дороги на хорошей машине — то, что нужно, чтобы прочистить мозги. Проезжая Бердск, силой неза..ранного мозга я пришел к тому, что люди будут отвечать на публичный опросник более идеализированно, чем с глазу на глаз. В Новосибирске удалось встретиться и переговорить лично с еще парой руководителей студий (в том числе — из Красноярска). В статистике добавилось угрюмых взглядов и пара жутких историй.

Приставал я к людям с одним вопросом:

ДА! Специфика отрасли.

Типовая ситуация — сайт после запуска остается на технической и гарантийной поддержке студии. Чтобы её обеспечить — нужны доступы. Как правило, это FTP/SSH/MYSQL/Админка, но бывает еще и кучка всяких хостинг-панелек (покупка доменов/панелька DNS-сервера/бэкапы/CPanel/AWS...) или рутовые доступы к серверам.

Часто клиент не в силах разобраться в куче этих аббревиатур, и у студии есть доступ ко всему. У более серьезных клиентов есть собственный it-отдел, который предоставляет необходимый минимум доступов к серверам и имеет свой регламент безопасности. На деле таких клиентов мало (я не беру случаи, когда на проекте военная приёмка), а те, что есть — часто враги самим себе.

Итак, классический случай: у студии на руках чертова туча паролей по каждому клиенту. Клиентов много. Время от времени на проектах нужно что-то править. Время от времени клиент просит поправить ВСЕ СРОЧНО (красным капсом). Время от времени на проектах меняются разработчики, контент-менеджеры, редакторы. И вот так, с ходу, и не разобрать, кому какие доступы от каких проектов реально нужны, а кто перебьется.

Классически ситуация решается файлом с паролями, на который установлен мастер-пароль, который знают почти все в студии. Что будет, если до него доберется какой-нибудь упырь?

Результаты опроса — очень показательны: все всё прекрасно понимают.

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

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

Но по факту дополнительно инвестировать в безопасность не готовы ни клиенты (во всяком случае, пока не долбанет), ни сами студии.

Причин тут несколько.

Это сложно

Чтобы обеспечить безопасность на высоком уровне, недостаточно время от времени читать статьи о взломе гугла на хабре и периодически менять скомпрометированные пароли. Есть форумы по безопасности «для своих», и там весело. PoC (коды, юзающие дыры в безопасности), которые мне доводилось прочувствовать, ой как не ограничиваются банальными sql-инъекциями и xss-атаками — с этим, наверное, большинство грамотных разработчиков умеет бороться «из коробки».

Это дорого

И в это мало кто готов вкладываться. Если заниматься вопросом всерьёз (например, пройти сертификацию по безопасности сайта ФСТЭК), то аудит безопасности нужно проводить после каждого изменения. КАЖДОГО, Карл! Либо морозить проект в «сертифицированном» состоянии. Что для нашей отрасли — неприемлемо.

Регулярные ревью проекта на безопасность — сложная процедура, требующая высочайшей квалификации и концентрации. Мало какая студия позволяет себе содержать специалиста по безопасности (он, кстати, в итоге и может стать точкой отказа, но об этом позже). Хороший безопасник был у Битрикса, но, судя по вакансиям — сейчас они активно ищут нового. Удачи!

Это геморройно и неконтролируемо

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

Точка отказа — почти всегда люди. Нет никакой гарантии, что админ не утащил пароли just for fun. Или что он — не внештатный «друг» ФСБ (мне такой случай известен). Стране нужны зарутованные сервера за рубежом, да! Нет никакой гарантии, что в коде проекта «случайно» не оставили закладку-backdore (например, отправляющую пароли на специальный email).

Занимательная математика

Люди бизнеса, поверхностно разбирающиеся в технических тонкостях безопасности, но вынужденные за неё либо платить, либо расплачиваться, интуитивно применяют вот такую формулу:

Для большинства сайтов:

• ВероятностьВзлома — константа, по умолчанию берётся за ДаКомуМыНахренНужны?
  
• СтоимостьМерПоБезопасности = ОченьМногоГеморроя.
  
  

На каждом конкретном проекте ситуация не изменится, пока не изменится знак в этом равенстве.

Утечки на стороне клиента

К сожалению, клиентов, которые готовы обеспечить меры безопасности сайта на своей стороне — единицы. Пароли на стикерах видел сам, и это непобедимо.

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

Рутовые пароли или пароли от хостинг-панелей хранятся изолированно (в отдельном софте). Доступ к ним есть у 2-х человек в компании. К этому довесок — регламент по регулярной смене паролей, регулярный code review. Для разработчиков хранение паролей ведём в Keyrights — надстройке над корпоративным порталом.

Когда мы впервые задумались над вопросом хранения корпоративных паролей с разделением доступов, мы устроили хакатон и сделали корпоративный парольник для коробочного Битрикс24. Он был написан на ангуляре и жутко тормозил. Не так давно мы переписали парольник на React.JS и теперь, как мне кажется, всё летает.

Разработку мы уже окупили, и, если кому-то из руководителей студий интересно — пишите мне в личку, подарим ключик за репост этой статьи. От вас — обратная связь так же в личку (что добавить, что убавить).