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

Когда мужчина колеблется, он хочет скрыть то, что он чувствует, а когда смотрит в сторону — то, что он думает.

Шантарам.

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

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

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

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

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

Есть ли в вашей студии человек, который, обидевшись на вас, сможет вам мстить, поимев пароли клиентских хостингов?

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

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

Мэри Поппинс.

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

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

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

Ну вы, блин, даёте…

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

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

23,3% опрошенных хранят пароли в одной системе. Всё доступно всем

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

41,7% опрошенных меняет клиентские пароли, когда долбанет (или есть предпосылки к этому), а 32,6 — не меняют и после

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

61,3% — опрошенные не особо-то и довольны уровнем безопасности для клиентов

Вопрос безопасности для студий в списке приоритетов
стоит где-то между зубным врачом и поносом

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

Это сложно

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

Это дорого

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

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

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

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

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

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

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

Что больше: ВероятныйУщерб * ВероятностьВзлома или СтоимостьМерПоБезопасности

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

• ВероятностьВзлома — константа, по умолчанию берется за ДаКомуМыНахренНужны?

• СтоимостьМерПоБезопасности = ОченьМногоГеморроя

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

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

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

Мнение: Максим Лагутин, CEO & Founder в SiteSecure

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

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

Минимально необходимые регламенты

Мер по обеспечению безопасности (иногда граничащих с шизой, типа регулярного прохождения сотрудниками детектора лжи) много:

1. Регламент по хранению и насильственной периодической замене паролей, предусматривающий:

   • запрет на хранение паролей на рабочих местах;

   • распределение доступов к корпоративным паролям по ролям;

   • изолированные (в разных программах и хранилищах) пароли, необходимые разработчикам и рутовые доступы (доступы к панелям);

   • штатные действия в случае подозрения на компрометацию пароля.

2. Регламент настройки серверов (у нас порядка 20 пунктов), включающий как минимум:

   • выполнения бекапов;

   • мониторинг серверов (кстати, новый, 3-й Zabbix хорош!);

   • устранения нештатных ситуаций.

3. Регламент проведения регулярного аудита кода.

4. Регламент увольнения сотрудников «по-хорошему».

5. Регламент регулярной проверки выполнения этих долбаных регламентов.

Доступы должны предоставляться по минимуму, а к рутовым паролям, панелям и инфраструктурно-важным компонентам должны быть ограничены 1–2 людьми в студии.

Как это у нас. Keyrights

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

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

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

Полезные ссылки

Полный текст статьи читайте на CMS Magazine