Безопасность NestJS в промышленной среде: контрольный список по угрозам

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

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

Начинайте с угроз, ценных ресурсов и границ доверия

Сначала нанесите на карту ценные ресурсы: идентификационные данные клиентов и сотрудников, данные клиентских организаций, денежные состояния и права на услуги, учётные данные, ключи подписи, аудиторские доказательства, административные действия и доступность службы. Затем проведите границы доверия между браузерами, мобильными клиентами, шлюзами, процессом NestJS, фоновыми исполнителями, базами данных, кэшами, объектными хранилищами, внешними службами, CI/CD и операторами. Отметьте, где поступают недоверенные данные, меняется представление личности, принимаются решения о доступе и записывается привилегированное состояние.

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

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

Не смешивайте аутентификацию с авторизацией

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

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

Проверяйте матрицу авторизации положительными и отрицательными примерами: анонимный запрос, чужая организация, другой владелец, отсутствующая связь, отозванный пользователь, пониженная роль, устаревший маркер, другой метод HTTP, пакетная конечная точка, сообщение WebSocket, повтор фонового задания и административное исключение. Записывайте важные для безопасности изменения в аудиторский журнал, защищённый от незаметного исправления. Если нужна помощь с реализацией, услуги разработки на NestJS должны превратить решения о личности в закреплённые меры защиты, проверяемые доказательства и рабочие процедуры.

Проверяйте смысл данных и ограничивайте злоупотребления

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

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

Ограничения частоты должны соответствовать ресурсу, которым злоупотребляют, и личности нарушителя. Вход, сброс пароля, подтверждение, поиск, выгрузка, дорогие отчёты и операции записи требуют разных правил. Сочетайте уместные признаки: учётную запись, учётные данные, клиентскую организацию, источник или ключ API. Один IP-адрес даёт несправедливый результат в общих сетях, а злоумышленнику легко его менять. Используйте общее хранилище для всех экземпляров службы, точно настраивайте доверие к сетевым посредникам, ограничивайте работу зависимых систем и определите, что безопаснее при отказе хранилища ограничителя: пропускать или отклонять запросы.

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

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

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

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

Считайте зависимости и результаты сборки составляющими промышленной системы

Фиксируйте точные версии зависимостей и собирайте систему только из проверенных описаний. Постоянно ведите перечень прямых, косвенных, разработческих, контейнерных, системных зависимостей и составляющих CI. Находка сканера — начало исследования: выясните, присутствует ли и доступен ли уязвимый путь, оцените открытость и дополнительные меры защиты, назначьте ответственного и срок, а затем проверьте обновление. Не отбрасывайте автоматически все находки с низкой оценкой и не останавливайте каждый выпуск из-за пакета, уязвимый код которого невозможно вызвать. Руководствуйтесь документированными правилами принятия риска.

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

Поддерживайте Node.js, NestJS, адаптеры, библиотеки аутентификации, клиенты баз данных и образы среды выполнения в пределах действующих версий. Планируйте небольшие регулярные обновления и отрабатывайте срочную установку исправлений. Удаляйте неиспользуемые пакеты и средства: код без активных вызовов всё равно расширяет цепочку поставки. Смежный материал о контрактах и отказах содержит руководство по созданию надёжных API на NestJS.

Записывайте события безопасности, не записывая секретов

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

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

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

Превратите перечень проверок перед развёртыванием в исполняемые правила

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

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

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

Привлекайте независимую проверку для устранения конкретного пробела в защите

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

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

• Моделируйте настоящую систему: перечислите ценные ресурсы и участников, проведите границы доверия, оцените правдоподобные сценарии злоупотреблений и отказов и превратите крупнейшие риски в проверки с ответственными.
• Проверяйте личность и каждое решение о доступе: полностью проверяйте сеансы или маркеры, по умолчанию отказывайте, сужайте права служебных учётных записей и испытывайте объект, организацию, действие и состояние.
• Ограничивайте работу с недоверенными данными: проверяйте форму и смысл, параметризуйте опасные операции, ограничивайте стоимость запроса и применяйте правила частоты по уместным признакам нарушителя.
• Уменьшайте раскрытие секретов и данных: используйте узкие служебные идентичности, доказывайте обновление и отзыв, передавайте проверенную область доступа к данным и испытывайте восстановление копий и изоляцию организаций.
• Контролируйте цепочку поставки программного обеспечения: фиксируйте версии, ведите перечень зависимостей, оценивайте доступность уязвимого кода, защищайте сборку, сохраняйте происхождение результатов и своевременно обновляйте поддерживаемые версии.
• Сделайте обнаружение и восстановление проверяемыми: записывайте ценные события без секретов, направляйте действенные оповещения, выпускайте изменения поэтапно, отрабатывайте происшествия и подтверждайте исправления.