Настоящий CTO: думай как технический директор - Алан Уильямсон

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

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

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

Заметки с полей

Это может случиться с каждым

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

Нас всех когда-то обманывали, в большинстве случаев безобидно. Тем не менее безопасность нельзя основывать на надежде, что мы не столкнемся со злоумышленником.

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

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

12.4. Утечка данных

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

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

12.4.1. Журналы событий

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

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

Заметки с полей

Однажды я работал с клиентом, который с гордостью уверял, что не хранит пароли конечных пользователей. Вместо этого он хранил хэши паролей с добавлением случайной строки (соли). Прекрасно. Однако в его системных логах все пароли находились в открытом виде, поскольку там сохранялись все запросы к API, и их было легко найти. Упс.

Журналы событий могут быть настоящей сокровищницей, и обычно они не так хорошо защищены, как базы данных. Тщательно следите за тем, что у вас регистрируется, и используйте средства маскировки конфиденциальных данных перед их сохранением в журналах. Не стоит использовать безопасность как оправдание тому, чтобы вообще не хранить логи, – просто следите за тем, что в них попадает.

12.4.2. Сообщения об ошибках

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

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

Раньше сайты, работающие на JSP, CFML или PHP, выводили на страницах ошибок полную последовательность вызовов функций (stack trace), значения переменных и параметры сервера. Эта информация не предназначалась для продакшена, но где-то по пути кода из разработки и тестирования ее вывод порой забывали выключить. Хотя такое бывает нечасто, сообщения об ошибках, если за ними не следить, могут привести к утечке большого количества информации.

12.4.3. Экспорт данных

Ваша система может позволять пользователям экспортировать данные или выполнять произвольные запросы / получать аналитику через интерфейс или даже через API. Не получает ли пользователь при этом доступ к слишком большому количеству данных?

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

12.4.4. Система контроля версий

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

12.5. Периодическая смена паролей

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

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

Нередко, особенно в различных старых системах, учетные данные для подключения к базе данных хранятся в файле XML, после изменения которого требуется перезапуск сервера. Это является проблемой для многих серверов приложений. В такой ситуации смена пароля