«Никогда не доверяй, всегда проверяй» и «Предполагать взлом»

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

• Использовать только надежные данные на стороне сервера (данные, которые были правильно проверены) для принятия решений по управлению доступом.

• Ставить запрет по умолчанию – перед началом работы все функции должны проверять авторизацию пользователя.

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

• Выполнять проверку личности (аутентификацию) и лишь затем – авторизацию (управление доступом).

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

• Проверять аутентификацию (AuthN) и авторизацию (AuthZ) для API в обоих направлениях (API → приложение → API).

• Блокировать доступ к любому не используемому приложением протоколу, порту, HTTP-глаголу, методу и всему остальному на сервере, PaaS или контейнере.

• Одно приложение на сервер, PaaS или контейнер в зависимости от модели развертывания и бюджета.

ПРИМЕЧАНИЕ. Валидация ввода была рассмотрена в первой главе, но данную тему мы будем затрагивать на протяжении всей книги. Если бы каждый разработчик программного обеспечения овладел искусством валидации, исчезло бы значительное количество всех типов уязвимостей во всех веб-приложениях. Принцип «никогда не доверять, всегда проверять» является самым важным и ценным уроком, представленным в книге.

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

Резервное копирование и откат

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

ПРИМЕЧАНИЕ. Алиса сохраняла копию своих файлов, чтобы работать из дома, то есть обходила политику безопасности, мешающую ей выполнять свои обязанности. В политике безопасности отсутствовало удобство. Поскольку Алисе нужно было работать из дома, она нарушила эту политику. Избежать данного обхода можно было бы посредством разработанного службой безопасности удобного, но в то же время безопасного решения (например, удаленный доступ в сеть компании через VPN).

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

• Резервные копии должны храниться территориально в другой точке (не рядом с базой данных и веб-сервером).

• Резервные копии должны находиться в безопасном месте (как в физическом, так и в цифровом виде) и быть защищены так же, как и производственная база данных или веб-сервер.

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

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

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

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

• Проводите учебные откаты. Серьезно!

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