Поиск в опубликованном словаре
Найдено опубликованных статей: 36
DMARC
DMARC является механизмом проверки использования почтового домена: он связывает домен в видимом поле From с прошедшим SPF или DKIM и публикует предпочтения владельца по обработке сообщений. Для понимания результата важны согласование доменов и граница проверки. DMARC не удостоверяет добросовестность автора и не гарантирует попадание во входящие. Ниже объясняем, какие вопросы он помогает решить владельцу бизнеса.
Многофакторная аутентификация (MFA)
MFA, многофакторная аутентификация, использует разные категории подтверждения при входе: например, знание секрета и владение средством аутентификации. Два последовательных действия не всегда означают два фактора. Для бизнеса важны также обязательность применения, исключения и восстановление доступа. Разберем, какие вопросы задать о защите учетных записей, не подменяя фактическую проверку названием функции.
Межсетевой экран веб-приложений (WAF)
WAF, межсетевой экран веб-приложений, анализирует проходящие через него HTTP-запросы и применяет правила обработки. Он может помочь ограничивать нежелательные запросы, но не заменяет исправление приложения, защиту учетных записей и восстановление. Для владельца сайта важно знать, какой трафик действительно проходит через WAF, какие действия включены и кто проверяет ошибочные блокировки.
SPF
SPF, Sender Policy Framework, позволяет домену описать разрешенные источники отправки для определенной SMTP-идентичности. Проверка не удостоверяет человека и не относится автоматически к адресу, который получатель видит в поле From. Для бизнеса важно различать опубликованную политику, фактический почтовый маршрут и результат конкретного сообщения. Разберем, какие выводы из SPF допустимы и где нужны другие проверки.
DKIM
DKIM, DomainKeys Identified Mail, связывает криптографическую подпись сообщения с доменом подписанта. Получатель проверяет подпись по соответствующему открытому ключу, найденному через домен и селектор. Это не шифрование письма и не удостоверение добросовестности человека. Для бизнеса нужно различать опубликованный ключ, включенную подпись и результат конкретного полученного сообщения.
Резервное копирование
Резервное копирование создает копии данных, из которых можно восстановить нужное предыдущее состояние после потери, ошибки или повреждения. Полезность копии зависит от состава, истории, доступа и возможности восстановления. Успешное задание копирования подтверждает выполнение своей операции, но не доказывает, что весь сайт или рабочий процесс удастся вернуть в нужное состояние.
Неизменяемая резервная копия
Неизменяемый бэкап защищает определенную копию или версию данных от изменения и удаления в пределах установленной политики. Такая защита зависит от сервиса, состояния блокировки, срока и полномочий. Она не доказывает, что данные чистые, ключи доступны или приложение восстановится: эти вопросы проверяются отдельно.
Целевое время восстановления (RTO)
RTO, Recovery Time Objective, означает целевое время восстановления определенного ресурса или сервиса после нарушения работы. Оно задается с учетом допустимого влияния на бизнес и зависимостей. RTO является целью планирования: время скачивания архива, результат одного теста и договорное обязательство являются отдельными показателями, которые нужно связать с четко заданной границей проверки.
Целевая точка восстановления (RPO)
RPO, Recovery Point Objective, задает требуемую точку, к которой должны быть восстановлены данные после сбоя. На практике его часто выражают допустимым временным разрывом данных. Цель сравнивают с реально пригодной точкой и записями бизнеса: расписание копирования или дата последнего задания сами по себе не доказывают достижение RPO.
Принцип минимальных привилегий
Принцип минимальных привилегий означает, что пользователь, приложение или процесс получает только права, необходимые для согласованной задачи, в нужной области и на нужный срок. Его проверяют по фактическим возможностям, а не по названию роли. Защищенный вход подтверждает отдельную часть безопасности: он не делает избыточные разрешения обоснованными.
Ключ доступа (Passkey)
Passkey, или ключ доступа, является средством беспарольного входа на основе пары криптографических ключей. Приложение проверяет ответ, связанный с его областью, вместо получения общего пароля. Для бизнеса важно, где хранится ключ, кто управляет устройством и провайдером, как проверяется пользователь и что происходит при потере доступа.
Менеджер паролей
Менеджер паролей помогает создавать, хранить и использовать учетные данные через защищенное хранилище. Для бизнеса важны сами пароли, владелец хранилища, общий доступ, восстановление и выход сотрудника. Доступ к записи в менеджере и доступ к соответствующему рабочему аккаунту являются разными объектами управления.
DNS
DNS, Domain Name System, связывает доменные имена с данными о ресурсах и сервисах: например, адресами сайта и почтовыми маршрутами. Для бизнеса важно знать записи, владельцев регистрации, зоны и изменения. Работа сайта не доказывает правильность почты, а открытая панель регистратора не всегда является местом управления действующей зоной.
DNSSEC
DNSSEC добавляет проверку происхождения и целостности данных DNS с помощью цифровых подписей и цепочки доверия. Для результата важны подписанная зона, корректное делегирование и валидирующий резолвер. DNSSEC не шифрует запросы и не доказывает безопасность сайта, а наличие одной подписи не подтверждает всю цепочку.
HTTPS
HTTPS защищает HTTP-соединение с помощью TLS: шифрование и проверка соответствующей стороны помогают передавать данные по защищенному каналу. Это свойство конкретного соединения. Оно не доказывает добросовестность владельца сайта, отсутствие уязвимостей приложения или безопасность хранения данных после их получения.
HSTS
HSTS, HTTP Strict Transport Security, сообщает браузеру, что к определенному имени нужно обращаться через HTTPS, и сохраняет это правило на заданное время. Оно зависит от области, состояния браузера и готовности сертификатов. HSTS не исправляет TLS-ошибки и не превращает сайт в безопасное приложение; расширение на поддомены и preload требуют отдельных решений.
Уязвимость плагина WordPress
Уязвимость плагина WordPress является недостатком компонента, который при определенных условиях может нарушить безопасность сайта. Сообщение о проблеме не доказывает взлом вашей установки. Для решения нужны точное название и редакция, версия, условия применимости и отдельные свидетельства возможного использования проблемы.
Межсайтовый скриптинг (XSS)
XSS, межсайтовый скриптинг, возникает, когда недоверенные данные интерпретируются браузером как исполняемое поведение в контексте приложения. Защита зависит от места вывода, безопасных способов отображения и обработки намеренно разрешенного содержимого. Наличие фильтра или политики CSP не доказывает исправление причины в приложении.
Межсайтовая подделка запроса (CSRF)
CSRF, межсайтовая подделка запроса, использует ситуацию, когда браузер отправляет учетные данные к действию приложения без надлежащего подтверждения намерения пользователя. Защита зависит от маршрута, проверки запроса и полномочий. Наличие входа, скрытой кнопки или токена в странице не доказывает, что сервер правильно ограничивает действие.
SQL-инъекция
SQL-инъекция возникает, когда недоверенные данные влияют на структуру или смысл запроса к базе вместо использования только как значений. Основное решение связано с безопасным построением запросов и привязкой параметров. Минимальные права базы и внешние фильтры полезны в своей области, но не заменяют исправление небезопасной логики.
CVE
CVE - общий идентификатор публично описанной уязвимости и связанная с ним запись. Он помогает сопоставить сообщения разработчика, инструмента и подрядчика об одной проблеме. Сам номер не показывает серьезность, наличие уязвимой версии на вашем сайте или факт взлома: эти вопросы проверяют отдельно.
CVSS
CVSS - стандарт описания технической серьезности уязвимостей. Оценку читают вместе с версией стандарта, вектором метрик, источником и условиями расчета. Балл помогает обсуждать последствия, но сам по себе не определяет риск для бизнеса, очередность всех обновлений или факт взлома сайта.
Уязвимость нулевого дня
Уязвимость нулевого дня, или zero-day, - ранее неизвестная проблема безопасности. Важно различать сам недостаток, способ его использования и атаку. Для владельца сайта практический вопрос состоит в том, затронута ли его установка, какие меры доступны сейчас и есть ли признаки чужой активности.
Сканирование уязвимостей
Сканирование уязвимостей - проверка согласованных объектов инструментом по определенным правилам и признакам. Оно помогает найти вопросы для подтверждения и исправления. Отчет зависит от области, доступов и возможностей проверки; отсутствие находок не доказывает полную безопасность сайта и не заменяет пентест.
Фишинг
Фишинг - обманный запрос, который побуждает человека передать данные, открыть опасный объект, разрешить доступ или выполнить действие в интересах злоумышленника. Он может прийти по почте, в сообщении, через QR-код или звонок. Для бизнеса важно проверять саму просьбу и ее полномочия, а не только внешний вид сообщения.
Компрометация деловой переписки (BEC)
BEC, или Business Email Compromise, - мошенничество, которое использует доверие к деловой переписке, чтобы добиться перевода денег, изменения реквизитов или передачи данных. Возможны подмена отправителя и использование настоящего ящика. Подозрительная инструкция сама по себе еще не доказывает взлом почтовой учетной записи.
Вредоносное ПО (Malware)
Вредоносное ПО, или Malware, - код или программное обеспечение, предназначенное для причинения вреда системе, данным или пользователям. На сайте оно может менять страницы, создавать нежелательные действия или сохранять чужой доступ. Симптом, уязвимость и подтвержденный вредоносный код - разные сведения, которые требуют отдельной проверки.
Бэкдор (Backdoor)
Бэкдор, или Backdoor, - скрытый либо недокументированный путь доступа к системе, который может обходить ожидаемое управление. На сайте одним из вариантов бывает веб-шелл. Обнаружение и удаление подозрительного файла еще не подтверждают, что закрыты все способы повторного доступа и устранена причина появления.
Программа-вымогатель (Ransomware)
Программа-вымогатель, или Ransomware, используется для блокировки доступа к данным и требования выкупа. Ситуация может включать шифрование, сохраненный чужой доступ и угрозу раскрытия скопированных данных. Поэтому возврат файлов, устранение доступа и оценка конфиденциальности являются отдельными задачами, а не одним результатом восстановления.
Утечка данных
Утечкой данных в рабочем обсуждении могут называть раскрытие, посторонний доступ или извлечение информации. Эти состояния важно различать по фактам. Опишите данные, период, источник наблюдения и пробелы; техническая оценка не должна автоматически превращаться в универсальный юридический вывод для любой страны.
SSRF
SSRF, или Server-Side Request Forgery, - подделка запроса, при которой приложение выполняет серверное обращение к неподходящему назначению под влиянием входных данных. Для защиты нужно контролировать текст адреса, фактическое соединение, перенаправления и сетевые возможности приложения. Проверка в браузере эту задачу не заменяет.
Политика безопасности содержимого (CSP)
CSP, или Content Security Policy, - политика, с помощью которой сайт задает браузеру ограничения для определенных ресурсов и действий. Ее нужно читать вместе с режимом и фактическим ответом страницы. Отчетный режим помогает собирать нарушения, но не блокирует их; наличие заголовка не доказывает исправление причины XSS.
Харденинг (Hardening)
Харденинг, или Hardening, - укрепление конфигурации системы: ограничение лишних служб и полномочий, работа с обновлениями и проверка функций после изменения. Полезный результат включает базовое состояние, исключения и владельцев. Это постоянный процесс управления, а не сертификат безопасности или замена разбору действующего инцидента.
Межсетевой экран (Firewall)
Межсетевой экран, или Firewall, ограничивает трафик по заданной политике между сетями, узлами или другими границами. Его эффективность зависит от места применения и фактического пути соединения. Правило на панели, сетевой экран хоста и WAF нужно различать; наличие любого из них не подтверждает защиту всех маршрутов.
Нулевое доверие (Zero Trust)
Zero Trust, или нулевое доверие, - подход, при котором расположение в сети и принадлежность устройства сами по себе не дают права на действие с ресурсом. Нужно отдельно понимать личность, устройство, задачу и разрешенные полномочия. Один VPN, MFA или приобретенный продукт не подтверждают внедрение такого подхода целиком.
Правило резервного копирования 3-2-1
Правило резервного копирования 3-2-1 означает три экземпляра важных данных: оригинал и две резервные копии, размещение на разных носителях и хотя бы одну копию в отдельном месте. Это принцип разделения, а не гарантия восстановления. Права, история, защита удаления и проверка рабочей функции требуют отдельного внимания.
Выберите понятие по задаче бизнеса
Технический термин полезен, когда помогает принять решение. Если клиенты получают подозрительные письма от вашего имени, нужно разобраться с доменом, учетной записью и отправляющими системами. Если подрядчик предлагает включить второй фактор, важно понять, какие роли и способы входа будут охвачены. Если не проходит форма после включения фильтра, нужен разбор конкретного запроса и границы защиты.
Словарь связывает такие вопросы с определениями, но не предлагает универсальную настройку для любого сервиса. Понятие описывает механизм. Ваш фактический результат зависит от конфигурации, доступов и выбранного объема проверки. Поэтому после чтения стоит записать один вопрос владельцу системы или подрядчику: что именно мы хотим подтвердить и какое наблюдение будет достаточным для следующего решения.
В опубликованном русском разделе сейчас доступны тридцать шесть самостоятельных понятий. Это начало проверенного набора, а не заявление о полном охвате всех терминов отрасли. Поиск работает по названию, сокращению и связанным формулировкам. Отсутствующий термин не означает, что проблемы не существует; можно воспользоваться подходящим руководством или описать задачу для уточнения.
От понятия к проверяемому вопросу
Не сравнивайте защитные механизмы только по знакомости названия. Разные средства работают на разных участках и отвечают на разные вопросы. В таблице указаны направления разговора с ответственным специалистом. Она не является заключением о текущей настройке вашего сайта или домена. Подтверждение требует наблюдения в соответствующей системе и явного ограничения сделанного вывода.
| Понятие | Какой участок обсуждаем | Что спросить у ответственного |
|---|---|---|
| DMARC | Аутентификацию почтового домена | Какие отправляющие потоки проверены и что осталось неизвестным? |
| MFA | Факторы входа и восстановление | Для каких ролей действует правило и как проверен резервный путь? |
| WAF | Фильтрацию запросов к приложению | Какие пути проходят через контроль и кто разбирает ошибочную блокировку? |
| SPF | Разрешенные источники для MAIL FROM | Какой домен проверялся и не превышен ли бюджет DNS-проверок? |
| DKIM | Подпись и домен подписанта | Каковы d= и s=, и проверено ли новое сообщение у получателя? |
| Резервное копирование | Пригодные копии данных | Какой состав и какой результат восстановления проверены? |
| Неизменяемая копия | Защиту от изменения и удаления | Какой объект, срок и режим подтверждены? |
| RTO | Цель по времени восстановления | Где начинается отсчет и чем заканчивается приемка? |
| RPO | Нужную точку данных | Как подтверждены пригодность копии и сверка записей? |
| Минимальные привилегии | Действия, область и срок доступа | Соответствуют ли фактические права рабочей задаче? |
| Passkey | Средство входа и владение ключом | Как проверяются пользователь, восстановление и отзыв? |
| Менеджер паролей | Хранилище и исходные аккаунты | Кто управляет данными и что меняется при уходе сотрудника? |
| DNS | Записи и владельцев сервисов | Где действующая зона и кто принимает изменения? |
| DNSSEC | Подписанные данные и доверие | Проверена ли цепочка, а не только наличие подписи? |
| HTTPS | Определенное защищенное соединение | Какие конечные точки и сертификаты проверены? |
| HSTS | Память браузера и область HTTPS | Готовы ли имена, поддомены и восстановление? |
| Уязвимость плагина | Применимость и свидетельства | Совпадают ли пакет, версия и условия? |
| XSS | Вывод в браузерный контекст | Как недоверенные данные отображаются безопасно? |
| CSRF | Намерение запроса и полномочия | Что подтверждается до выполнения действия? |
| SQL-инъекция | Структуру запроса и значения | Как привязаны данные и ограничены права базы? |
| CVE | Идентификатор и применимость | Совпадают ли продукт, версия и условия? |
| CVSS | Техническую серьезность | Какая версия и какие предположения оценки? |
| Уязвимость нулевого дня | Хронологию сведений и исправления | Что известно и что изменено на сайте? |
| Сканирование уязвимостей | Область и находки проверки | Что подтверждено и что осталось вне охвата? |
| Фишинг | Обманный запрос и действие | Как подтвердить просьбу независимо? |
| BEC | Поручение и почтовый доступ | Подтверждены ли личность, полномочия и операция? |
| Вредоносное ПО | Назначение кода и наблюдения | Что подтверждено кроме общего симптома? |
| Бэкдор | Скрытый или повторный доступ | Какие пути и полномочия проверены? |
| Программа-вымогатель | Доступность, контроль и данные | Какие результаты восстановления подтверждены? |
| Утечка данных | Раскрытие, доступ и извлечение | Какой объем и период установлены? |
| SSRF | Назначение серверного обращения | Куда фактически соединяется приложение? |
| CSP | Политику браузера и ее режим | Отчет это или применяемое ограничение? |
| Харденинг | Базовое состояние и исключения | Кто подтверждает нужные функции? |
| Межсетевой экран | Политику трафика на реальном пути | На какой границе действует правило? |
| Zero Trust | Ресурс, действие и условия доступа | Кто и почему получает полномочия? |
| Правило 3-2-1 | Разделение копий и рисков | Какие состояния реально можно вернуть? |
| Проверка результата | Наблюдение в заданном объеме | Какие условия, данные и ограничения записаны вместе с итогом? |
Как читать отдельный термин
Начните с краткого определения, затем посмотрите на границы механизма и пример. Следующий шаг: сопоставить описанное со своей системой. Наличие знакомого пункта в панели не подтверждает, что функция применяется к нужному пользователю или маршруту. Спросите, какие права требовались проверяющему, когда получено наблюдение и может ли другой ответственный воспроизвести его в согласованной среде.
Полезно разделять четыре состояния: подтверждено в указанном объеме, обнаружена ошибка, не проверено, неприменимо с объяснением. Пустое поле нельзя автоматически считать отсутствием проблемы. Такой способ чтения подходит и для предложения подрядчика, и для внутреннего списка задач. Он помогает сохранить неизвестные участки вместо того, чтобы скрыть их за общим словом настроено.
- Назвать рабочий процесс, который нужно защитить.
- Выбрать связанное понятие и прочитать его ограничения.
- Определить владельца системы и допустимый объем проверки.
- Записать наблюдение, дату и оставшиеся вопросы.
- Выбрать инструкцию или услугу для конкретного следующего шага.
Чем словарь отличается от инструкции и услуги
Статья словаря отвечает на вопрос, что означает понятие и в каких пределах его можно применять. Руководство разбирает последовательность решений: например, как отличить подмену отправителя от захвата ящика. Страница услуги описывает согласуемую работу, доступы и приемку. Эти материалы дополняют друг друга; чтение определения не является выполненной настройкой или проверкой.
Если требуется изменить рабочий сервис, не переносите пример из определения прямо в конфигурацию. Сначала выясните зависимости и полномочия. Особенно важно это для отправляющих систем, административных ролей и фильтрации платежных маршрутов. Владелец может самостоятельно подготовить перечень вопросов и компонентов, а техническое изменение согласовать с тем, кто отвечает за соответствующий участок.
Откуда берутся определения и как понимать даты
В отдельных статьях указаны первичные источники: спецификации, документация разработчика или официальное руководство. Источник описывает механизм в своей версии и области применения. Он не устанавливает автоматически состояние вашего сервиса. Мы отделяем такие сведения от собственных поясняющих таблиц, условных примеров и наблюдений локального эксперимента.
Дата материала относится к содержательному пересмотру, а не к каждому техническому запуску сборки сайта. У протокола и документации могут быть свои даты и версии. Например, статья о DMARC ссылается на RFC 9989 и RFC 9990, опубликованные в мае 2026 года. Вопрос о поддержке конкретного поведения вашим провайдером нужно проверять отдельно от факта публикации стандарта.
Как пользоваться материалами в разных странах
Русский язык не определяет страну размещения бизнеса, правила его провайдера или применимое право. Поэтому словарь использует общие технические понятия, а обязанности по хранению, уведомлениям и работе с персональными данными не выводит из языка посетителя. Если задача включает такие вопросы, понадобятся сведения о конкретной организации и соответствующие компетентные специалисты.
CyberFixCrew применяет практические израильские знания в защите сайтов и цифровой инфраструктуры к задачам бизнеса по всему миру. Мы не выводим качество конкретной конфигурации из географии компании. Если нужен технический разбор, опишите систему и вопрос без паролей и клиентских архивов. Начнем с согласования цели, доступного объема и понятного результата.